Ok, here are a few suggestions for later revisions of the API. These are mostly things that i think are long overdue, or that could be handled in a better way.
1) All objects, for example buffers, textures etc. should be handled, initialized and configured without binding semantics.
A bit of clarification: I understand the optimizations achieved with first-bind setup, so it should remain an option with creation. However, the state of the buffers/textures should be handled on a per-object basis, not on a per-binding basis.
I suggest this change for flexibility, especially with texture sampling states, which are handled really inadequately in my opinion. This can be done relatively easily by changing the “target” arguments on various state functions to object names (IDs).
2) The default framebuffer should NOT exist at all.
Clarification: The concept of a unique, preset framebuffer that is required to render to the screen is inefficient for many effect techniques. A better approach would be to allow any framebuffer to set ONE of it’s color buffers, regardless if it is a texture or a renderbuffer, as the screen output. I am fairly confident that this can be handled more efficiently in the driver rather than having the application rebinding and blitting between framebuffers.
Of course, given this change, the default framebuffer could still exist, just as long as it is not the only method of screen rendering.
3) There should be better integration between the OpenGL and OpenCL pipelines, preferably by implementing OpenGL as a "subset" of OpenCL (could be in the driver only, just as long as there are no conflicts/flushes when switching APIs).
This could lead to some interesting ideas, such as something like the D3D “compute shaders”. Pretty useful stuff, it would be nice to see it done in a completely integrated manner.
If i am suggesting something impossible/stupid, please explain the issue. I do think, however, that these changes are possible and could lead to a more modern and powerful OpenGL.