This problem will fade over time, and the situation will become like in the CPU world. Do you use to care if your CPU has the intructions run your C program?
And precisely how long will that be? 3 years? 5? 10?
If we don’t have basic useability now, it doesn’t matter if we will be in the right place 10 years from now. Because everyone writing performance apps will be using D3D, and OpenGL will be that thing that CAD programs/non-Windows programs use.
And to help me in this discussion let me remember some old words from John Carmack regarding the resource queries:
First, I do not subscribe to the notion that what Carmack says is the divine word of God, or even more significant than what any other graphics programming professional would say. Plus, logic is with me; the source of an argument or position is irrelevant to the veracity of that argument or position.
In that vein, do note that the ARB promptly shot his nonsesne about non-querryable limits down flat. The mere thought of a low-level graphics API being required to do multipass or whatever it takes to make shader X work is sheer lunacy. It’d guarentee that no glslang implementations would even exist (let alone be at all trustworthy) until hardware was actually capable of virtualizing its limitations. Certainly, you couldn’t write performance code based on it; you have no guarentees, or even educated guesses, about what the compiler, multipasser, etc is going to do with it.
While the ARB agrees with him about not trying to support any further form of assembly (to GL’s detriment), they do not accept that hardware limits need to be virtualized. As they pointed out, if an implementation wishes to do so, they can expose an extension to virtualize these and require the glslang implementation to run any shader it is given.
Equally importantly, Carmack just wants someone else to write the dull, boring, boilerplate code for him. He wants driver developers to write code that takes a shader and breaks it down into multiple passes for inferior hardware so that he doesn’t have to do it. He’s looking ahead to his next engine knowing full well that he’s going to have to write some boring code into that engine to be able to run on R300 hardware just as much as R600 with the same shaders.
And regarding low level interfaces:
Considering that Carmack made a game that can’t be fully run on current hardware, I don’t think he’s the kind of authority you want on performance apps (note: I realize this is irrational, but Carmack bashing is a hobby of mine, so I felt the need to indulge 
).
More on-point, nobody’s arguing that higher level interfaces aren’t the future. The question is much more a matter of when that future gets here.
To my mind, high-level languages are a luxury until the day that hardware limits are actually virtualized (via reasonable means. IE, not because the driver decides to multipass). Once that happens, any usefulness of low-level languages is gone, and we therefore ought to use something else. In that vein, I agree with Carmack that glslang shouldn’t allow for querryable limits, but I add to that that it shouldn’t exist yet.
I recall this quote from Sid Meyer’s Alpha Centauri:
“Technological advance is an inherently iterative process. One does not simply take sand from the beach and produce a Dataprobe. We use crude tools to fashion better tools, and then our better
tools to fashion more precise tools, and so on. Each minor refinement is a step in the process, and all of the steps must be taken.”
Effectively, this means that attempting to leap over a step simply because we know that it will eventually lead to something else doesn’t make it a good idea. This isn’t an API refinement like VBO, which theoretically we could have had at GL1.0. This is a significant feature; a technological advance.
You can skip a step when you’re climing the ladder, but if the rung you’re going to is too high, you’ll pull a muscle or something on the way. CPU improvement didn’t skip the “code in assembly” phase; imagine what would have happened if they did. Imagine sending out your source code to be compiled for their CPU and hardware setup. Maybe it’ll work, but maybe it won’t. There’s no way for you to tell. And your consumers don’t want to here, “Oh, set this build parameter” or whatever other nonsense; if it doesn’t work, it isn’t worth their time.
It isn’t that glslang isn’t a good idea to have even today. The point is that, for quite some time, CPU code was written in both C and assembly. There were good reasons for this; it was a transition period and to not have one of them would have made the transition more painful. It doesn’t make sense to try to just skip the assembly phase just because it’s going to end eventually.
I think the ARB is living in the Ivory Tower, where they can just go for the right answer, when they don’t realize that the right now answer is not only not a bad idea, but quite useful and crucial for many applications.
