So the problem you’re running into is the question of whether support for old architectures should indefinitely hold back the adoption of new features or languages in future kernel versions. Rust in the kernel was added as a way for developers to explore whether the tradeoff between not supporting all future capabilities and adopting a more modern programming language works out. Nothing in the kernel core uses and relies on Rust so far, and to the best of my knowledge, no adoption of Rust in any of these places is planned as of today. So the use of Rust is limited to places which are of zero interest to older architectures. And it’s also not like the old kernel versions are going away. It’s perfectly viable for maintainers of old hardware to remain on older versions of the kernel.

OTOH, there is a desire from a group of kernel developers to implement to implement the code they contribute to the project in Rust. The want new shit to be working, and write support for it in a language they consider suitable for implementing the support faster, more maintainable and safer than in C. Should those people be held back by architecture support for architectures that haven’t seen new hardware in decades? Would that imply that the kernel developers cannot decide to drop support for old architectures? What would any such requirement mean for the long term future of the Linux kernel?

And this is why very long support windows are great. All the corporate persons and the bleeding edge devs can improve off into the sunset while a stable base for non-dev culture human people who want to get things done and have them keep being done rather than requiring remakes every $timeperiod (~3 months for rustc, ~10 years for c++xx culture target changes, etc) exists.