To re-iterate what gankro said, we care a _lot_ about making sure that it's trivial to update your Rust. Your ABI compatibility comment is correct, but the rest of them aren't. We only break backwards compatibility in very few cases: if there's a soundness hole, or if we have to fix something in certain underspecified areas of the language. For those latter ones, if it's not a trivial fix, then it's a no-go, and even if it is, we do warnings until we don't see them in the ecosystem any longer.
But really, it's not about rules-lawyering over technicalities about what our policies are: the underlying attitude we share towards new Rust versions is that it should be trivial to upgrade. And we collect data to make sure that we're on target there: part of it is the train-based release strategy, part of it is stuff like testing everything on crates.io, part of it is things like the community survey, where most people said their code has never broken, and if it did, it was extremely easy to fix.
True stability is impossible for almost any language out there, especially one with a nontrivial type system.
An example of a thing considered "trivial to upgrade" over is when the stdlib adds a new method to a type. Libraries may already have implemented a method of the same name on that type via a trait. In this case, folks upgrading would have to explicitly specify which method they're talking about.
It's these kinds of things that are not counted as breaking changes, because the alternative is freezing the stdlib forever. Other languages have the similar problems.
New releases are tested on the entire ecosystem to ensure that this rarely happens, if ever.
But really, it's not about rules-lawyering over technicalities about what our policies are: the underlying attitude we share towards new Rust versions is that it should be trivial to upgrade. And we collect data to make sure that we're on target there: part of it is the train-based release strategy, part of it is stuff like testing everything on crates.io, part of it is things like the community survey, where most people said their code has never broken, and if it did, it was extremely easy to fix.