Back in the late 70's and early 80's, the state of the art for programming was Edward Yourden's books on Structured Design. One of the points they made was to clearly separate State from Data. The variables you are describing would mostly have been described as State variables.
Although distinguishing between State and Data can help clarify thinking, Computing Theory, in particular Turing Machines and the techniques of Lambda Calculus, show that other than the distinguished "current" instruction, in theory State and Data are indistinguishable.
For example, in
for K = 1 : 5
K is both State (row number) and Data (content to print), and there can be no useful distinguishing between those.
All of which is to say... It doesn't matter. You do not need to distinguish these as being somehow "different".
Consider your example of a CUDA variant being available. There might be use for a variable that stores that fact, but that variable is probably not what should be passed to the lower level routines. The lower level routines should either be passed a function handle that does the work "somehow", or else should be passed a flag that indicates whether to use the CUDA variant. Because even though a CUDA variant might be available, that does not mean that it should always be used. The user might know that they have a slow GPU, or the user might want to compare the results of CUDA vs non-CUDA because the user is seeing significant round-off effects.