I get the impression that Rust revisions are (at least intended to be?) backwards compatible: [0]
Are there are good workarounds when breaking changes to occur? No idea if/how well breaking language changes can be isolated to stay within individual crates.
> I get the impression that Rust revisions are (at least intended to be?) backwards compatible
I don't think that matters at all. If I try to build a new project with an older version of Rust, the compiler will still throw errors when stumbling upon newer features.
Is there any language toolchain that isn't absolutely static capable of having not only backwards compatibility but also forwards compatibility? If I try to open an MS Office XP file in MS Office 97, it will fail. If I try to run a new linux application that uses a new syscall in an older kernel, it will fail. If I try to use structural pattern matching in Python 3.9, it will fail. How is Rust any different?
If the concern is that projects are using "too new a rustc version", then your beef is with those projects, but be advised that demanding open source projects not use newer versions of their toolchains can be a big ask that increases their workloads and they might not be amenable to cater to your usecase.
Finally, because every Rust version is backwards compatibility, there's no reason for builders and developers to not use the latest stable release as quickly as feasible, all existing projects will continue compiling.
I don't think that matters at all. If I try to build a new project with an older version of Rust, the compiler will still throw errors when stumbling upon newer features.