but, in all, it is more all about trade-offs.
nothing is perfect, FWIW...
for what things it is not within ones' power to change, they can take it as it is, and make "locally optimal" tradeoffs within the set of available options.
Thing is though, there is absolutely no tradeoff with the bind-to-modify model. The model itself gives you absolutely nothing in return, and introduces a whole heap of needless and painful careful state tracking. Complex and fiddly code paths that have unwanted consequences have a price beyond the time taken to write them; you've also got to maintain the mess going forward, and if it's bad enough it can act to prevent you from introducing cool new features that would otherwise be utter simplicity.
This was obviously broken when GL_ARB_multitexture was introduced, was even more problematic when GL_ARB_vertex_buffer_object was introduced, and the ARB themselves are showing little inclination to resolve it. Thank heavens for GL_EXT_direct_state_access, which even id Software are using in much of their more recent code (see https://github.com/id-Software/DOOM-3-BFG/blob/master/neo/renderer/Image_load.cpp#L453 for example).
What's particularly annoying is that bind-to-modify was recognised as a potential problem as far back as the original GL_EXT_texture_object! See http://www.opengl.org/registry/specs/EXT/texture_object.txt. Even more annoying is that while some good new functionality has come in with a civilized DSA API - sampler objects, the promotion of the glProgramUniform calls to core - a whole heap has also come in without one - vertex attrib binding, texture storage, etc.
Shrugging it off with "ah just accept it, sure that's the price of portability" is not good enough; OpenGL used to be a great API and should be one again, and people acting as though this is not a problem (or even worse - acting as though it's somehow a good thing) are not helping that one little bit.
Edited by mhagain, 13 February 2013 - 06:45 PM.