What you are describing happens all the time. Usually the toolchain provider will continue updating a list of known issues for some time after EOL. Beyond that you have third parties that do it for decades, if the platform is big enough. They collect bug reports from the industry, investigate them, then create lists that you subscribe to. Those lists include detailed examples, explanations, and usually linter rules to detect code that could trigger the bug.

The truth is: If the toolchain was good enough to ship your product, has time to go EOL, and then you do a patch that surfaces an esoteric toolchain bug, then the odds are that you'll know exactly what triggered the bug and you can work around it by writing different code.

Because even if the newer shinier compiler/toolchain had the issue fixed, most companies wouldn't upgrade to it at that point. It's almost never desirable to change your toolchain for a shipping product, you're just introducing more unknowns.

Fortunately there are more than two compiler versions in the world.

It's easy to install different rust toolchains. You could increment the toolchain version forward and find the next toolchain to include the fix, or even backport the fix to a custom toolchain if you want.

The comments acting like Rust is breaking code all the time are also pretty lost. I've been developing Rust since +/- the 1.0 days and this isn't a common occurrence. When something does need to change it's usually a tightening up of something that was incorrect in the past, and it's easy to fix.

Some of these comments act like everything is going to collapse at any moment and the old code will be unusable, which is pretty ridiculous

Coding around compiler bugs is pretty standard practice in usecases where you have some random vendor compiler that is based on some ancient gcc if you’re lucky or completely in-house if you’re not.