Expecting people to search through large, multi-file codebases to even understand the nature of what the code is even trying to achieve (let alone what the problem is and how OpenGL is involved with it) is not reasonable.
In general language usage, those words may mean what you’re talking about. But within the specific context of rendering APIs and their functionality, those words have very specific definitions.
As previously stated, it would be very helpful for your understanding of things if you stop trying to impose your meanings and expectations on things. Spend less time telling experienced people they’re wrong and spend more time trying to understand what things actually mean to these APIs.
You can choose to rage against those definitions all you like, but all it will be is screaming into a tornado. Nobody will understand you, everyone will think you’re crazy, and you’ll eventually be whisked off to the Land of Oz.
Then go write a graphics driver. Because that’s the only place where you’re are going to get that kind of freedom.
No graphics API has ever promised to let you try anything, to expose the exact, precise details of the underlying hardware. All of them abstract away these differences into specific patterns and impose limitations on those patterns in accord with that abstraction. That is the nature of the beast.
If you direct, unfiltered access to the GPU, then you need to bypass these APIs and write specific drivers for specific GPUs. Good luck with that.
And good luck getting OS’s to let you. And good luck getting NVIDIA to give you the detailed specs to their GPUs that you’d need to do it.
As previously stated, your expectations are simply unreasonable.
But there are compiler limitations. Compilers are based on abstractions of hardware. Hardware can have more features than compilers expose.
For example in assembly, you can do tricks like changing the stack address for the return pointer, thus allowing a single conceptual “return” instruction to return several layers in the stack.
C and C++ do not let you do this. The hardware can do it, but you cannot. And yes, at the advent of C and languages of similar abstractions, some people did create an “uproar”.
But in the end, C won out over the uproar. Because the cross-platform compatibility and structured programming model of C was far easier to use than writing code for specific pieces of hardware. And also because C compilers could get smart enough to make use of such functionality automatically (see tail recursion). So you didn’t even have to give up the performance benefits in quite a few cases.
What gets to be a “RUNTIME/HARDWARE issue” is a matter for the abstraction to decide. You can either use the abstraction or go write your own compiler.