This suggestion is much more (for me) than a convenience. This is essentially providing a (simple) means to specify a value that changes rarely. Alfhoneses suggestion that rather than making the index follow, but have another value running around that increments whenever primitive restart happens has legs in it and not a bad idea; it just means that one gets the value through another lookup into an array, buffer object or something else. My suggestion with or without Alfhonses modification to it means that the entries in the vertex cache should be discarded at primitive restart. For my use case, that will have no impact on performance because a fixed primitive uses the same value. In general, this idea is just to avoid using up the extra memory and attribute slot needed to get the same functionality. Doing it the way I have to now, the vertex cache is a miss anyways.

Not that I'm adverse to any of the suggestions above, I can see cases where they would be useful. But in the interests of discussion, if it changes rarely, would drawing them as separate batches with a uniform change between them suffice? Or perhaps a GLSL "gl_ArrayID" extension for glMultiDrawArrays/Elements(), with geometry with the same attribute grouped together?

Rarely in my case, and to what wish to apply this, means that the indices named between the primitive restart are disjoint, so for my use case the vertex cache issue is mute. For record, my use case is user interfaces, where the index is an index for "what node" to use... UI drawing has a tendency to have an enormous number of nodes where each node does not have a huge number of triangles to it... so breaking each node into a separate draw call is performance suicide.
Another way to get similar to what I want is to add glMultiDrawElements the ability to specify (or have it given) for each index range,

this would also give me what I am after, but I prefer the primitive restart index because glMultiDrawElements method forces the bookkeeping updating of the arrays to use more than the primitive restart way in my use case.

This would potentially break with GL_UNSIGNED_BYTE or GL_UNSIGNED_SHORT indices; how do you specify a value of gl_SomeNiceName greater than 255 or 65535 in those cases?

Break is not the correct word, the correct word is that it is much more limited. The value taken from the index stream has the range by the index stream type, thus if drawing with GL_UNSIGNED_BYTE, then the value is an integer in the range [0,255] and for GL_UNSIGNED_SHORT is it in integer in the rage [0, 65535].

Alfonse's suggestion of having the value start at 0 and increment whenever restart is encountered is nice though, and though using that would be harder, it is growing on me.

Additionally, looking at the way of tweaking glMultiDrawElements, one can see that there are roads open for other tweaks. Another way forward is a draw_indirect2 idea as follows by tweaking GL_ARB_draw_indirect

which by itself is not so interesting, but then augment GL_ARB_multi_draw_indirect to a GL_ARB_multi_draw_indirect2. Going further, the data for someNiceName does NOT then really need to be a 32-bit unsigned integer. Instead it can be like a "pseudo-attribute", a munge of bytes and the DrawElementsIndirect2 (and MultiDrawElementsIndirect2) would then have further arguments specifying how to interpret that munge of bytes as follows: