Isn't the whole point of semver that it's not complex or nuanced? A version is either backward-compatible or it's not.
The fool's errand would be expecting semver to encode all information about a version. That's not its purpose. Its purpose is to convey to users of a version some basic information about how it relates to previous versions from a user's perspective.
For more complex or nuanced information, the semver triad is not the place to look. Use git history, readme, changelog, release notes, etc.
It is tiresome to see people dismiss semver as bad because they misunderstand its purpose. "Semver is bad because it isn't what I think it should be" (then publish your own scheme), or "Semver is bad because it doesn't encode everything" (only the source itself could do that), or "Semver is bad because it would require some arbitrary numbers to increment faster than I am comfortable with" (i.e. "eww, semver has cooties").
SemVer does not handle complex or nuanced information, which is one of the beefs the article has with it. SemVer does have answers for the question it asks "what if you only broke it for 1% of users?" -> "tough luck, increase the major version" It seems that the author constructs a straw man for SemVer (albeit from real life examples) and then complains that it no longer serves its purpose.
Contrary to the article SemVer is okay to determine whether there is a compatibility break, as long as it is followed to the letter. Is is overly strict? Yes it is, but it does guarantee results. Maybe an argument should be that not all libraries should not follow SemVer because it is a burden similar to certifications and regulatory procedures.
What if a patch or minor version change causes the library to break?
This was a question a lot of people had to ask when npm didn't use package-lock.json and the `--save` option would automatically select a range of allowable versions.
Your coworker could `npm install` something entirely different than you and have all sorts of bugs because of it. And there are plenty of documented cases of exactly this happening.
The issue I see with semver is that it generally does not survive contact with the real world. People make mistakes when they package software, especially when they do it "without any warranty, express or implied". There's simply no substitute for testing whether a new package version will work or not; so in a realistic sense, semantic versioning simply doesn't work.
I agree that the version number does not give you a guarantee, that the software is without bugs. However, it does work the other way around: if the major version was bumped then you know something has broken and you will have to modify your code. If it was a bug fix release and something breaks, it is on them, not on you (as in, rollback your dependency upgrade and complain on their bug tracker). That is, if you did not rely on buggy behavior in the first place.
As a side effect, if you really try to follow SemVer it will force you to think ahead a bit more because the fact that you broke the API is reflected in something quite obvious, rather than buried in a change log somewhere.
I mean, you're still going to be issuing release notes.
I think it's important to realize that semver isn't about how accurately you summarize things. It's about what actions your customers will take from your version numbers.
If they're enterprise, then they'll expect to be able to apply anything short of a major version number change with an in-place software update, and they expect that they will not experience any significant or foreseeable breaking changes. It doesn't matter if you're using semver or not, this is how your enterprise customers will behave.
Part of the issue here, I think, is that you need to be roadmapping your project. If you're just churning and churning and producing features and changes all the time and you're not planning that, say, changes X and features Y go with v.Next, then, yeah, semver is going to be really hard. However, even if you're on the extreme end of agile you had to decide some set of features that made your product v1.0, didn't you? Why can't you do that again? You just have to decide how many features result in a major increment.
It does seem to lead you down the Java/Chrome versioning problem where the primary number just doesn't have meaning anymore (i.e., both Java and Chrome are technically still at v1.x, but they dropped that major version number because they realized they were never going to increment it).
Edit: I realize I'm describing semantic-ish versioning, but I'm of the firm belief that rules are meant to be flexible, rather than blindly followed. RFC 2119 is not a suicide pact, as it were.
Compressing complex, nuanced information into three integers is a fool's errand.