These two issues sound totally different, a 2018 project that doesn’t use nightly should absolutely compile today, unless there was a soundness issue. (And the vast majority of projects don’t use nightly features.)

The latter bit is the opposite, that is, old compilers can’t possibly know about new features, and that’s not a compatibility issue. That’s an older tool chain issue, or maybe a “community prefers newer tool chains than distros do” issue.

But how in gods name can you call a language "maintainable" if just compiling it after certain time requires some detective work to find the right rustc/cargo versions?

And that's only the first problem with maintaining old Rust projects. There are so many other issues, specially with projects created in very early Rust days.

Tell me, have you ever seen a go project failing due to similar issues? Python had this problem once (2 to 3) and they are still apologising for it.

(Not trying to start a language flame war. I like Rust and want it to succeed. But right now things are a bit chaotic)

I mean, it shouldn't! After some time, you'd be using a newer version. You want to be using an old rustc to compile a project created later in time. There are very very few languages that do not add new features over time. Even Go adds new standard library functionality or toolchain features in new releases.

The Python 2 to 3 situation is very different, that is about new versions not compiling old code. We go to great lengths to make sure that that works well in Rust.