It's a weird phrasing, but I agree on the compiler topic, maybe for other reasons: an important project like Linux should not really on a single compiler. I think it is good to have the ability to use either GCC or LLVM to build the kernel. That ensures that you don't accidentally rely on a compiler bug, no lock-in, ... .
For C and C++ code you want to be able to build with different compilers.
I think that also makes sense for Rust, the language and the compiler should be two separate things and there should be multiple compiler suppliers.
Are there arguments why this would be less relevant for Rust than C?
Clang has been a viable compiler for only about a decade--a third of Linux's existence--and could itself build Linux only a few years ago. Prior to clang's existence, Linus is on record as saying that he didn't care about compatibility with other compilers, which at the time would have been something like Sun's C compiler.
So it's very much against the historical policy of the Linux kernel to not be tied into a single compiler, even if it is a welcome change in policy.
Moving Linux and FOSS away from GCC runs the risk of enabling the mass adoption in industry of LLVM/Clang and the drying up of open source commits to either project once Clang is in a place where it does not generally require community contributions.
For C and C++ code you want to be able to build with different compilers.
I think that also makes sense for Rust, the language and the compiler should be two separate things and there should be multiple compiler suppliers.
Are there arguments why this would be less relevant for Rust than C?