Everything said by Brother Bob and Mhagain is correst, but maybe it sounds a little bit complicated (although it is not).
Let me try to make it clear...

1. Not anyone, but only hardware vendors can make extensions. It is logical since extensions are part of the drivers, and only driver writers know what their hardware supports.

There are some non-hardware vendor-written extensions in the registry already which indicates that anyone can, in fact, write extensions. It doesn't take be a hardware manufacturer to suggest something. A lot of useful support functions can be suggested that no hardware manufacturer have thought of yet. For example, GL_MESA_window_pos was first suggested by Mesa, and was then fairly quickly adopted by the bigger vendors and promoted to an ARB extension, and then finally promoted into the core API.

The authors of gDEBugger also has an extension in the registry.

2. If only one vendor supports some functionality, then appropriate prefix/suffix is used (NV, AMD,...) Sorry, Brother Bob, for repeating this.

3. If at least two vendors support some functionality, then EXT prefix/suffix is used (prefix for constants, suffix for functions).

4. If at least two vendors support some functionality, and the committee (ARB) decides it is something that should be a part of the core, the prefix/suffix changes to ARB.

The numbers are not necessarily that clear and well defined. There are extensions with vendor-tags that are supported by multiple vendors, and even extensions that have not been further promoted at all so there's no EXT or ARB equivalent. And funnily enough, I did find some ARB extensions with only one supported hardware vendor. Although, that database did look a bit incomplete or outdated so I would take that information with a grain of salt. In any case, there are no definite rules like that.

8. Claiming that appropriate version of OpenGL is supported is not a guarantee that it is true. I won't start a debate about it, but there is a plenty of examples.

In practice I agree that the support may not be what it's supposed to be, but it is a violation with the licensing of the OpenGL brand and any claim the vendor makes about supporting a version. I would call that a driver bug rather than an issue with relying on the version information. It is a problem with the driver that we software developers end up having to deal with.

Regarding your number 6, the example of GL_ARB_shader_objects, which was quite different in some key areas to the core 2.0 implementation of GLSL, should be sufficient warning that ARB and core are not necessarily always identical. Having said that, I don't think we'll be seeing that happen again.

Thanks for the example! I know it is not always the case, but an exception only confirms the rule. ;)

There are some non-hardware vendor-written extensions in the registry already which indicates that anyone can, in fact, write extensions.

I agree that extensions can be proposed from "the outer world", but GL functionality is implemented in drivers, so actual development is done on the hardware vendors' side. OK, I as to restrictive. My mistake.

In practice I agree that the support may not be what it's supposed to be, but it is a violation with the licensing of the OpenGL brand and any claim the vendor makes about supporting a version. I would call that a driver bug rather than an issue with relying on the version information. It is a problem with the driver that we software developers end up having to deal with.

As mhagain already said, what's the purpose of GL_ARB_occlusion_query if it actually doesn't function. Another case (Intel again) is problem with multisampling. Intel does not support multisampling in pre-HD2000 GPUs, although it claims GL 2.1 is supported. Well, my humble opinion is that it is brainless to advertise GL 1.2 (because of missing functionality) when there is a full shader support. Extension strings should list all supported functionality regardless of the advertised GL version.

I have to apologize because my statement number 6 is not correct.

6. If the driver supports particular ARB extension it also supports core equivalent and vice versa. ... Well, if the core version exists, both ARB and core functions point to the same entry.

I carried out some experiments, and they proved that core, ARB and EXT versions of the same function may point to different entries.