editions

That's true for all editions, including the very first Rust 2015 edition. One example: Rust 2015 got NLL is year 2022, one year after Rust 2021 got it and four years after Rust 2018 got it — which means, ironically enough, that if you want to backport some code written for Rust 2015 in year 2024 it may be easier to port it to Rust 2018 than to stay with Rust 2015 if you want to use old compiler.

The only way to stay with old version of Rust compiler is to, essentially, fork everything and stay in your own little island.

I recommend you to find someone who told you this blatant lie and kick him. All prior edition have to stay compatible with all prior code (with some small caveats), but they are not frozen and they are not meant to be frozen.

One caveat that I see is missing from the editions discussion is that for this kind of project where stability is the most valued asset you should stick to at most current-1: the current edition is technically live and, while always backwards compatible, it's not necessarily forward compatible, as extensions are allowed to some degree

This is also not completely true; the old edition is also technically live, since, while it's not permitted to change the meaning of code that compiled under old compilers except across an edition boundary, it's permissible for a new compiler to accept code under an old edition that an old compiler rejected. So, I can write Rust 2015 code with compiler 1.80 that will not be accepted by compiler 1.50, for example, because the new compiler accepts more code than the old one did (borrow checker changes, changes to core and std to name new examples).