That's exactly my point. This sounds exactly like an candidate of an
extension, that developers will be forced into the awareness that the
"sharp" tool may not exist everywhere.
An extension "singular" isn't a solution. Let's run with the premise that significant performance caveats remain unresolvable between different implementations (I'm not convinced of that premise as I believe those caveats can largely be avoided, but for the sake of argument, let's assume you're right).
An extension communicates 1 bit in capabilities (present or absent, 1 or 0). But from all the discussion about this, it does seem to me that you'd imply that there exist at least a couple performance caveat bits (like maybe 3 or 4?) depending on the assemblage of flags you'd use.
The test of "Is this a good bit of information to pack into an extension" is the following question: "Does all that is contained in the extension fall into a 1-bit sized bucket?". The answer to this for glMapBuffer[Range] is (going by your theories) is no. It doesn't. You'd need a couple new extensions (like 3 or 4?) to communicate more bits.
Even if we assume we'd want to provide multiple extensions to convey all the performance caveat bits of glMapBuffer[Range] (most assuredly, we don't), defining such an extension set would be difficult because the conditions for caveats do not depend mutually exclusive sets of functions/flags. They appear in combinations of them. So for instance, you could have: