Yes, I am aware that the spec file will not be migrated to a comprehensive, parseable format (XML?) during the next two decades.
There is a common naming scheme: the name of the function is "BindBuffer". The name for this function used by C, to avoid conflicts with other names because there's only one way to do that in C, is glBindBuffer. A valid C++ name for it would be gl::BindBuffer.
Agree on a consistent naming scheme, adhere to and enforce it.
The prefixes exist only when you're talking about a specific language binding, not the concept of the function. This makes it possible to have a binding that doesn't do stupid things like gl::glBindBuffer, which is redundant.
Nonsense. Those are Core OpenGL extensions. They don't have ARB suffixes because they are simultaneously core features and extensions.
Except... when that's not true. ARB extensions that model functionality present in a higher core version have function names identical to the identical core functions, both in the spec files and in reality. This makes sense insofar as they are indeed the same functions as their core counterparts, however, the extension name gives no hint to this, making it unnecessarily confusing, error-prone, and hard to parse.
ARB_vertex_buffer_object is not the same as the 1.5 buffer object stuff. They don't use the same functions (glBindBufferARB vs. glBindBuffer), and the interaction between them is not specified. There is no guarantee that glBindBufferARB could take, for example, GL_UNIFORM_BUFFER.
By contrast, ARB_vertex_array_object is the same as the 3.0 vertex array object functionality. They use the same functions, they use the same enumerators, etc. When ARB_vertex_attrib_binding comes around and adds functions that change VAO state, it is automatically compatible with ARB_vertex_array_object
That's what "core extensions" mean. And that's why it's important to know what is and isn't a core extension.
The real problem is that the only way to tell that something is a core extension is to actually look at it. The spec files won't tell you.
Well they're not going to retroactively rename over half of their ARB extensions; that would break plenty of code. They're also not going to adopt a brand new convention, as this would make everything inconsistent (thus working against your desire for consistency).
Naming these extensions differently would be less ambiguous (BRA would be a good choice to indicate that it's really a backwards-extension, or if people find the association with female underwear too repulsive, something like BACK or DOWN or COMPAT would do too... anything that gives the user a darn clue).
Also, again, it's not for backwards compatibility. It's more for forwards compatibility: being able to use ARB_separate_shader_objects as an extension on 3.3 hardware, but as a core feature with well-defined interoperability with other extensions and core features.
As opposed to ARB_vertex_buffer_object, who's interaction with GL_UNIFORM_BUFFER is unspecified.
What compiler? Certainly not a C compiler of any kind. And certainly not a C++ compiler. Not unless you put your enums in a C++11 strongly-typed enumeration or something.
the compiler has no way of detecting and raising an error.
In any case, while this would be nice where possible (obviously glActiveTexture can't do it) consider the fact that it took me maybe 2-3 days of work to turn the .spec files into XML. The work it would take to collate all of this information, across innumerable extensions and functions and so forth, would be immense. You're looking at a good month+ of 8 hour days.
If they can't take the time to turn the .spec files into XML (and either port their processing systems to use the XML or simply have a reverse transformation process to go from the now source XML to the .spec format), then they certainly don't have the time to collate this kind of data. This data actually was initially used in the 1.1/1.2 era, but it isn't any anymore, due to the explosion of new functions, extension functions providing new parameters, etc. It just became too much to be able to do.