That's exactly my point. To my best knowledge "semantic versioning" refers to Tom Preston-Werner's codified version, which is not valuable for the aforementioned reasons. The general idea behind semantic versioning is of course valuable, but we already had a word for that... it's called versioning.
I thought you were separating semantic versioning practices and the Semantic Versioning codification.
Versioning includes many practices outside semantic versioning obviously. Rational numbers. Odd minor version is unstable. Last number at least 90 is unstable. No patch versions. No minor versions. Incompatible minor versions. Dates.
I rejected your claim library authors rarely define the public API. And Hyrum's law makes semantic versioning imperfect but not useless.
Versioning is fundamentally the communication of changes to users, and those changes are inherently semantic. Semantic versioning as a general idea is thus not different from versioning as usual---one or more numbers compared in the lexicographic order relative to importance. The actual version format is at best superficial and distros have done a good job to unify all different version formats.
The Semantic Versioning codification does attach specific semantics to major, minor and patch versions, but those semantics can't exist without the public API. So the codification itself is nothing more than a stipulation that there should be three major categories of changes. The codification would have been much more useful if it included specific rules for particular languages and contexts, and there are indeed some noble attempts. But they are hardly complete and users can't rely on that. For example Rust Cargo defines a relatively complete semver guideline [1], but it doesn't define whether changing the minimum version of Rust required (MSRV) is a breaking change or not. So a minor version upgrade may or may not increase MSRV and users have to consult the release note to find it out anyway. If users can't be entirely sure if the minor version is breaking or not for their purposes, is the entire stipulation worthy?
> I rejected your claim library authors rarely define the public API.
I agree that they do think they define the public API, sometimes only in their minds, sometimes in a form of the public source code. But the source code is only a portion of the public API, and any major libraries have suffered from numerous mismatches between authors' and users' definitions of the public API. The public API in semantic versioning clearly means the latter, so my claim that library authors rarely define the public API (of the second sense) still holds. But I should have been more clear about two different notions of the public API---sorry for that.
> Hyrum's law makes semantic versioning imperfect but not useless.
The general idea, yes (you can still communicate that changes have happened). The codification, no (three-part versions are no longer useful).
Generations of programmers come up writing web services where the router forms a hard API layer and they don't see the point in public/private/protected any more, because nobody is ever linking against their code so it doesn't matter.
Generations of programmers wrote application code where access levels didn't matter. The concept of public and private API is relevant in web services even when language access levels aren't. And erosion is not evident to me.