Just a thought … What would be better for GLSL than being replaced by Cg? Nothing, I guess. 
Anyway, I wouldn’t use a shading language without parametric polymorphism (think C++ templates). Even Cg interfaces seems to be more like the parametric polymorphism than inclusion one. I use C++ templates in CUDA C and it’s VERY useful for writing uber kernels.
Yep… I see in the CL registry they’ve added a nice C++ binding (cl.hpp) along these lines.
I dont see any need for OO support shader languages, since the concept of an object has no evidence in the shader paradigm. Besides shaders are not consider large-scale modules, not yet.
In the near future shaders will completely replace the API, and become part of the unified CPU language…
You’re probably right. Probably makes more sense in the long run to have 2 or more languages to battle for a given programming task, each with its own problem reformulation requirements.
The “worst” part of GPGPU right now is having to manage parallel reformulations to scale with core counts and the glue necessary to connect it all together with the runtime. Not so bad perhaps here with the initial baby steps, but as things more forward a bit in complexity, CUDA, CL, Larrabee/Ct, etc. start to look a lot better on a standalone basis, if you get my drift. Not so much the OO end of it but the multi-language aspect that really chaps my arse.
I’m more afraid of OpenCL it gonna end totally open to the IHVs where it fails stability and lags behind its current spec version.
For me, “Open” implies “optional” which means it’s up to whatever platform to provide whatever version, whatever quality 
I see GPGPU is a contemporary tech that will die slowly sooner as soon as we get n-core CPUs capable of even handling ray-tracing, then good bye to APIs
The binding mechanism must die!
OpenGL needs to have an API-oriented versioning scheme.
With clear cuts, not just profiles of one version.
More something like:
3.y line
3.y line: compatibility profile
(until here, everything is legacy from the current situation)
4.y line: incompatible with 3.y, only where necessary
(tada progress and an api cut)
The 3 and 4 line can be supported on drivers.
Each app can use 3 OR 4 but not both.
Graphic cards should be multi-tasking.
Old apps can run in a 3.y context while new apps written in 4.y context run in the newer 4.y context.
Anyway, here is the link to my reply on the OpenGL 3.2 official feedback thread:
http://www.opengl.org/discussion_boards/ubbthreads.php?ubb=showflat&Number=261969#Post261969