OK, so GL_ARB_texture_storage gave us immutable texture specification. You bind the texture, call glTexStorage* on it, and the storage is immutable.
Buffer objects should be able to have something similar. So there would be a glBufferStorage function that allocates X bytes for the buffer, but also marks it as immutable. So you cannot call glBufferData on it ever.
The main problem this avoids is someone trying to use glBufferData every frame to invalidate it, but maybe gets the hint or size parameters wrong. That's an improper invalidation of the buffer, and it results effectively in creating a new buffer object with theoretically new characteristics. So instead, you invalidate it with glMapBufferRange, and this extension would introduce a specific API for invalidating buffers: glBufferInvalidate.
The latter might only be usable on immutable buffers. But that's debatable.
However, this should also do some other things. Since it's an either/or process (either you use glBufferStorage or glBufferData, just like with glTexStorage), we can take the opportunity to correct some mistakes with buffer objects. Namely: hints.
Hints with glBufferData are optional, in the sense that you can more or less ignore them. If you use GL_STATIC_DRAW, you can call glBufferData as many times as you want.
With immutable storage however, hints should be requirements. I don't suggest keeping the previous hint enums around, as they're confusing to users and are too fuzzy (where is the dividing line between STREAM and DYNAMIC?). Whatever the new "hint" system is, it should absolutely affect the behavior of the buffer object.
If there is an equivalent to "DRAW", for example, then it should be enforced. DRAW means that you will write but not read. So it should be an INVALID_OPERATION to use glGetBufferSubData or glMapBufferRange for reading. Same goes for "READ" and "COPY".
I don't really have a fully developed suggestion for a new hint system, but whatever it is should specifically have a semantic component.