I read it all. Frustration is understandable, due to promises made for the past 2 years. However this is not a HUGE tragedy. In conclusion it just means more work for programmers.
This was clearly handled badly in terms of communication, specially the lock down. Being an open organization all meetings should have transcripts, and that way we would know what happens behind closed doors, at least that would allow us to understand the rational behind certain decisions and who is opposed certain features.
I take from rbarris comments that basically OGL 3.0 is the maintenance of the “Status Quo”, OGL3.0 is a competitor to D3D, however the lag of features for real-time developers using either API is pretty much the same. If you want the advanced feature you are dependent of drivers and extensions and have to jump thru a couple extra hoops to get the features you get for free in a D3D context.
Basically what people wanted was:
a) A simpler API that could have a fresh start with new drivers done from scratch.
I think the vendors looked at this and thought - hum writing new drivers does not come cheap, and we still have to support all the legacy code anyway, plus we already have to do D3D10+ that covers 85% of the real-time market anyway. Let’s just do what we do every time we need to add new features to OGL, create a new context that relies on extensions - this way, those that want to move forward can use this and those that don’t, don’t have to implement the extension. This basically translates into a new path to be worked around by app programmers = more work for us, and less work for driver makers. So this makes some twisted sense.
You can bet that 3D application companies like autodesk, luxology and others that have advanced OpenGL application like Maya, Mudbox, Modo are not very happy with the way this turned out. At the same time certain groups within autodesk (the CAD/VIZ devision) are content with it, since they don’t have to radically change their base code.
Since the main driver makers are part of the group, they share part of the blame.
b) A cleaner, leaner API that does not have 5 ways of doing the same thing.
Well that already exist up to a point and it’s called OpenGL ES 2.x you can use it on the desktop already but since it is only a wrapper of OGL 2.x code anyway it may not make much sense. However if you want a leaner, cleaner way of writing you OGL application that only uses shaders you can use this API syntax instead. Does not make sense performance wise, but it’s a possibility. In the end OGL3.0 initially promised less hurdles to be jumped and this spec ends up adding a couple more.
Basically what this means is instead of shrinking your code, you now have an extra context to support and basically add a couple of thousand lines to your code if you want to support a OGL3 context in addition to any other context you may have in your engine.
In conclusion, people are disappointed not so much due to the technical details. In one way or the other there is an extension or workaround that enables feature X to be done on OGL3.0 by adding complexity to the mix, and reducing you target market to people that have cards and drivers that actually can run this kind of context. We wanted a OGL on a diet (i think even the khronos ppl) and it turns out that all it was done these past two years is talk about loosing weight while at the same time eating cake 
Not enough fat was cut, i blame the drive makers for that, not enough was added in a proper way, DSA extension should be central to a new object programming model. There was not enough courage from the board members to break away from the legacy code like it was done from OGLES1.x to OGLES2.x Instead a new getto was created for OGL3.x applications. This specification increases fragmentation of code, and in all aspects is a mess to handle. It will get you from point A to point B just like D3D you just need to code a few hundred extra plumbing lines of code, and pray that the hardware and driver can handle your code correctly.
In the end it would be nice to know why things turned out like they did. Since the initial vision was much more ambitions. I think it is one of those cases where…
“You want answers?!!”
“I want the truth!!”
“You can’t HANDLE the truth…!!”
Edit: After reading Barthold’s version of the truth i really almost can’t handle it. Why didn’t you come up with this in Jan08? Even earlier, at the time the object model problems began, there is allot of smart people on these forums i exclude myself that could work on the problem, and possibly present alternatives.
I think the conclusion here, is khronos needs to communicate more, and be a lot more open with the communities with witch it should write open standards, and not simply present open standards that do not please the majority of the community.
I hate to admit it it but Korval is right, nobody like to use OGL as it is. It’s a fat API with a programming model from the early 90s. But if you want cross-platform then you have to use it. And there are other reasons why one has to support it, but it’s not exactly a joy to use or maintain. OGL needs to turn into the original OGL3.x vision, and it needs to do it FAST, or face extinction in less than a decade.