Actually, to be pendanic, probably the appropriate behavior should be the following: glGenQueriesARB and glDeleteQueriesARB should generate an error between glBeginQuery[ARB] and glEndQuery[ARB] (as those should respect the GL_ARB_occlusion_query spec, not the core spec). It doesn't matter, however, whether you use the ARB or core version of begin and end query as the active state is aliased between the two.
The debate about glGenQueries and glDeleteQueries (the core functions) are more tricky as when these were originally introduced to the core spec they behaved like their ARB counterpart and only since version 3.0 they started to behave differently (at least according to the spec).
So the thing is, I still would say that this is a specification bug as it makes 3.0 non-backwards compatible with 2.1 (even though it should be as no features were actually removed there). However, if we really have to insist on it, then it means that from 3.0 glGenQueries and glDeleteQueries should behave differently than glGenQueriesARB and glDeleteQueriesARB.
This shouldn't be a problem in general, but think of the following case:
1. Somebody implements an application on a GPU supporting OpenGL 3.3 (compatibility profile).
2. The application is meant to be backwards compatible as it doesn't use any new features besides e.g. OpenGL 2.0.
3. He/she puts a glGenQueries or glDeleteQueries call inside glBeginQuery and glEndQuery (this should work fine, according to the OpenGL 3.3 spec).
4. Now somebody wants to execute the same application on a GPU supporting only OpenGL 2.1 (occlusion queries are in core there too so one might expect that it should work out-of-the-box, considering that compatibility profile should be fully backwards compatible).
So unintentionally, the developer made the application non-backwards compatible with OpenGL 2.1 despite he/she used compatibility profile and didn't use any GL 3.x features.




