Also posted here:
Just to add something.
I looked at the way context creation is done.
The application should be able to
a) get major, minor and core or compatibility profile (this is done and good, please make this kind of a thing consistent across all khronos api’s so you only have to develop it once.)
b) when an application wants to exist let it present a version and profile to the driver.
The driver then decides to execute it or gives an error with does not have <needed version> for application: <application name>.
(There seems to be inconsistencies between the GL and GL ES about this.
Also I’m not sure if I read correctly
but please allow for a general api mechanism where the application can just do a call with the version and profile it wants.)
This can be useful for all the api’s, dealing with changing specifications.
Making a general thing across all khronos api’s benefits from only having to develop it once.
old applications will be recognizable by new drivers because of the calls.
New applications can just work on new drivers since the drivers can have a very good idea of what is asked. You can theoretically even break the api constantly and still have old and new applications running on new drivers without problems related to compatibility.
(Provided that the driver writers can keep up implementing everything.)
No danger for legacy + able to change everything without problems related to the way changing something could mess up expectations between applications and drivers.