Right, I get it. I was merely stating that the parts of OpenGL that don't resemble a modern GPU have been removed. That is a fact.
EDIT: I would also like to add that only in the strictest and most painful sense was the legacy OpenGL "just an abstraction". Before, it was a simplistic cross-platform layer over actual hardware and while abstract to a degree, hardly attempted to shield the programmer from hardware details. It's notable that the features that OpenGL "happened" to include as the "core abstract GL state machine" mapped pretty much 1-to-1 onto SGI's tiered hardware offerings at the time. In other words, what made the cut was very much based on real hardware, hence, the evolution of the API was not based on random abstractions that seemed like a good design [cough]. The legacy-GL-on-modern-hardware -- we refer to it as "fixed function emulation", since the abstraction is so far removed from actual hardware nowadays. Perhaps this isn't a "good reason" to change the abstraction, but it is notable that if the entire legacy API can be emulated using the newer API, then the legacy API may not deserve to be part of the driver (which takes a lot of time and effort to develop) so much as another library. That is to say, if one were to change it into terms of "computability", there are some things that cannot be computed using the FF, but the reverse is not true, i.e. FF can compute a proper subset of the programmable pipeline. In fact, this is pretty much the exact idea that Gallium takes in Mesa -- and why you can implement D3D / GL ES / core GL / legacy GL on top of it.
Now, on to the real issue that I raised, which is a purely API design choice. Direct state access vs bind-modify-unbind. The consequences of bind-modify-unbind have been lamented by developers for _ages_. As a response, the newer GL sampler objects do not use that. However, the old style API (you know, the thing we've been lamenting over for ages) does not have a modern equivalent. Please tell me how this has ANYTHING to do with GPUs? It's pure and simple API cruft. The API is _not_ consistent with itself.
EDIT: I would also like to add that only in the strictest and most painful sense was the legacy OpenGL "just an abstraction". Before, it was a simplistic cross-platform layer over actual hardware and while abstract to a degree, hardly attempted to shield the programmer from hardware details. It's notable that the features that OpenGL "happened" to include as the "core abstract GL state machine" mapped pretty much 1-to-1 onto SGI's tiered hardware offerings at the time. In other words, what made the cut was very much based on real hardware, hence, the evolution of the API was not based on random abstractions that seemed like a good design [cough]. The legacy-GL-on-modern-hardware -- we refer to it as "fixed function emulation", since the abstraction is so far removed from actual hardware nowadays. Perhaps this isn't a "good reason" to change the abstraction, but it is notable that if the entire legacy API can be emulated using the newer API, then the legacy API may not deserve to be part of the driver (which takes a lot of time and effort to develop) so much as another library. That is to say, if one were to change it into terms of "computability", there are some things that cannot be computed using the FF, but the reverse is not true, i.e. FF can compute a proper subset of the programmable pipeline. In fact, this is pretty much the exact idea that Gallium takes in Mesa -- and why you can implement D3D / GL ES / core GL / legacy GL on top of it.
Now, on to the real issue that I raised, which is a purely API design choice. Direct state access vs bind-modify-unbind. The consequences of bind-modify-unbind have been lamented by developers for _ages_. As a response, the newer GL sampler objects do not use that. However, the old style API (you know, the thing we've been lamenting over for ages) does not have a modern equivalent. Please tell me how this has ANYTHING to do with GPUs? It's pure and simple API cruft. The API is _not_ consistent with itself.