As a consumer, that first number becomes irrelevant if it's not the "is this going to break my shit?" number. Why have it? It's not communicating something useful to me. Cut it.
But it does communicate something useful! It tells you "this isn't a huge change, it's a minor change that just happens to break backwards-compatibility in some fashion". Most products reserve major version number changes for when there's particularly large or important changes to the product. Committing to semantic versioning means losing that. The upside is your package manager knows when it's safe to silently upgrade. The downside is the actual humans looking at your product have no idea which versions they need to actually do some work to support, versus which ones just have minor breaking changes that may not even affect them.
I expect to audit dependencies I use when they break API compatibility in any way. That's a feature, not a bug. Having a "well, the maintainer think this is a bigger break" number does nothing. It's still a break. It's still a major version change.
In Semver the first number is not "is this going to break my shit?", it's "is it potentially breaking my shit?" in this proposed alternative the first number is "this is definitely going to break your shit", the second number is "this may break your shit, check the changelog to see if it affects you"
Having a "may" in there is the same thing as a "will" from the perspective of downstream. It still needs to be audited and checked. There's no value in splitting this out.
