At no point I understand that Linus is going to consider replacing C with Rust for the Linux kernel, neither tomorrow nor maybe even in 10 years. All we can conclude, for what he said, I guess, is that at least he doesn't reject it violently as he has always done with C++.
As I understand it, the rejection is logical: Unlike C's freestanding environment (which Linux relies on), C++'s still requires a runtime for <new> and <exception>, and that makes it a no-go, because the Linux kernel would have to be fundamentally redesigned to run on such a runtime. Also, C++'s freestanding environment leaves too many things implementation defined, which means kernel developers would have to beg the compiler developers to provide sane implementation-defined behaviour, and except for the last few years, dealing with GCC developers has been quite a headache for the kernel developers.
It is important to note that most of the embedded C++ environments used with e.g. microcontrollers aren't really C++, but a subset of the freestanding C++ environment; in particular, exceptions are not supported. So, while an enthusiastic C++ programmer will just say "then only use the subset you want!", the problem is that when you have a project that potentially will live for decades, you want something to rely on, instead of relying on implementation-defined behaviour and the assumed benevolence of the compiler developers.
In comparison, freestanding C environment is
simple and well defined.
I believe this also shows why developing an OS kernel requires either a strictly defined compiler, or close cooperation with compiler developers. I would be particularly interested in the interaction between Rust and Redox developers, especially since both are actively evolving. In this PC era, I suppose any truly friction-causing issues are only discussed in private, without movement-starting paper trails... I liked the honesty of LKML, where idiotic suggestions like kdbus got called out in public.