There's a lot of misuse or misunderstanding of SemVer in the wild. Common example we all experience: people break the public API but do not increment MAJOR.

I think a big part of this is that yes of course people are not reading the documentation, but we could dig a pit of success for these people to fall into instead of trying to teach them all how to use it correctly. Presently, the names of the numbers is closer in semantics to importance assigned to a number instead of semantics related to the change itself.

I propose that we rename these numbers in the docs to something semantically aligned with what an increment in the number does instead of what position it holds in the sequence.

There's a lot of room for wishy washy interpretations of what "major" and "minor" mean (especially for people who don't read the spec in detail, or lack experience to learn from someone who understands it). There is much less room for ad-hoc interpretation when they have something like "Breaking.Adding.Fixing" instead.

"This is the number I increase when it breaks someone who updates the package version".
"This is the number I increase when it fixes a bug but doesn't add a feature or break the API".
Etc.

Perhaps you disagree with the specific words in my proposal, if so, do you disagree with the general concept of renaming the concept in the docs too?

This change should be fully backwards compatible with the package ecosystem and (as I see it) does not "add a new feature".

If agreed I can submit the change request. I think this would make a gentle nudge on the global package ecosystem towards a slightly better better state.