Of course there's always Hyrum's Law[1], which can be summed up as

> All observable behaviors of your system will be depended on by somebody.

Even minor bugfixes will at some point invariably break somebody who depended upon the broken behavior. So semver really boils down to a human assessment of whether any potential breakage is incidental or intended.

[1]: https://www.hyrumslaw.com/

Hyrum's Law reminds me of Frank Borman's "A superior pilot uses his superior judgement to avoid situations which require the use of his superior skill". On the user side Hyrum's law is a situation where you're going to need superior skill to fix it. You should instead have used superior judgement to avoid this situation altogether.

As a library author I don't feel there's any value in considering Hyrum's Law. I can't help those poor fools, for all I know they're relying on me not updating the documentation to warn them they shouldn't rely on undocumented behaviour I'm about to change... Rust provides a pretty clear line in the sand on API changes we can use to choose semver policy. If your program has a proc macro to copy-paste sections of my source code into yours so you can access my non-public functions, I can't see that from where I am and you're lucky it ever worked, I am under no obligation to ensure it magically stays working in my next bugfix release.

And I agree with you on the solution: version the language (or whatever other more conceptual thing) by year and the program by semver. It’s the only thing that makes sense given the constraints.