Not exactly what you're asking, but here's a wrench I've seen in semver at work. Let's say I do a overhaul to a library; either I rewrite the logic or write a new interface. I also write "shim code" that's "supposed" to be backwards compatible. It's a huge change, and the company isn't really big enough to have formal q&a or significant testing. Personally, I tend to write a lot of shim-code, but try and be aggressive about deprecating it--it's more work, but is more politically viable than getting everyone to update their code /and/ troubleshoot/trust a big change. The consensus we had was a major version bump when that's introduced and another when the shim code gets deprecated--but nobody really wants that in practice. (I never did come up with a good answer)

Also, we decided that "stealing" major version numbers for speculative code was a bad idea. We'd have a lot of false starts that get abandoned and it got really confusing when the next major version got released (you're either re-using that version number or skipping a bunch).

Personally, I like semver, but think versioning mechanisms can differ (going from major OSes to small libraries I write at work) based on the needs. One thing I've noticed when working on artwork for clients, they get scared and confused by large revision numbers, so we tend to keep them fairly low by keeping internal version control numbers separate from review versions.