Uniform locations are “slots”, hence the numeration. […] Plus, there should be addition burden to “translate” exposed numbers to real slots.
I don’t know what you mean by “slot”. Uniform locations are arbitrary numbers. They have no meaning to the hardware. They’re not byte offsets into a buffer, or even 4D vector register numbers. If the latter were true, then a 4x4 matrix would have to take up 4 uniform locations, and they don’t.
That’s why uniform locations can be assigned arbitrarily by the user. If they were some kind of hardware byte offset into a buffer or something, the ARB wouldn’t give the user the ability to assign them arbitrary numbers.
So this “burden to ‘translate’ exposed numbers to real slots” already exists (if by “real slots” you mean “byte offsets”). I’m simply wanting the burden to be used for something useful.
Further more, if that number changes on every compilation, it wouldn’t alleviate catching errors, since behavior will change from compilation to compilation.
Let’s say that I forget to get the location of a uniform. Or maybe I have some convention for my uniform locations thanks to ARB_explicit_uniform_location, but I screwed up and forgot to assign that location in one shader. Either way, in my C++ code, I have some code that assumes that location 0 represents some variable.
Given an arbitrary assignment scheme for uniform locations (typically, based on the order defined in shaders), it is entirely possible that 0 may indeed represent that uniform. Thus, my code appears to work. And since the assignment scheme doesn’t “change from compilation to compilation”, I will never know about it.
At least, until I take my code to a different implementation that uses a different assignment scheme. Then it breaks. That may have been weeks or months since I wrote the original code that’s now broken. Tracking down the variable I forgot to initialize or the shader I forgot to set up properly will be a lot harder.
If the implementation starts assigning uniform locations from a random number, it is highly unlikely that any particular compilation of a shader will just so happen to pick 0 as the start. Therefore, it is very likely that my code will break the first time I try to use it. And if it doesn’t, it will break the second time I try to use it.
Thus it catches errors sooner rather than later.