Just to clarify, the real concern is the opposite of what you are showing, when the semver version advances faster than the "desired" version. So for example, something like Angular 1 (v2.5.6), because it contains a change that breaks 1.x.x users.

Regardless, "what's wrong" is that people just don't behave this way, and there's no way to convince them otherwise. For better or worse, semvers have taken on the dual role of "build version" and "public facing version" (probably because that's the only version users actually end up seeing out in the wild). So there is tremendous resistance to advancing the MAJOR portion of the semver faster than their "marketing" desires. I have been in many, many, frustrating arguments on GitHub where there are several users that are begging to simply release a package under a MAJOR update instead of (erroneously) under a MINOR version, because it is incredibly difficult and confusing when a subdependency of a subdependency picks up a seemingly innocuous change which is actually breaking solely because "it still felt like it belonged in this major version", and the "fix" for this on the user's end is super complex - having to dive many layers deep in the dependency tree and wrestle with a lockfile - all because the change "didn't feel 2.0 worthy".

In theory, if you can prove that a change breaks current users, there should be no further discussion, the change merits a major update. But you will be surprised how all of a sudden crazy unrelated arguments start popping up. Ultimately, its all because there is an emotional attachment to the leftmost number, simple as that. Look no further than Underscore's "romantic versioning" (https://gist.github.com/jashkenas/cbd2b088e20279ae2c8e ) drama back when SemVer was first introduced, when it was stated that it would be ridiculous for underscore to be at "version 157" or something had they followed semver to the letter. But again, its only ridiculous because people want to attach PR value to the Major version. It is absolutely not ridiculous from the perspective of knowing that there were 157 breaking changes, and 157.x.y won't work with 156.x.y.