If Rust truly is zero overhead on the C side of things then they should be just able to fork Linux indefinitely without any worry about what upstream does. Just fast forward every change and you're golden.
Then they can write every driver they can imagine to their hearts' content.
The fact they aren't doing this tells me that the promise that this won't impact C people at all isn't much of one.
It's like telling people who want JPEGXL in Firefox to "just" fork the browser, ignoring the massive extra effort that you actually have to convince everybody to use your fork instead of the original.
This is primarily around Rust filesystem drivers. If you want to run a filesystem but it's implemented in Rust, you'd have to use that fork. If another person had the same issue (say a GPU driver that some maintainer decided they didn't like because of the country of origin or some other petty reason), then that would have to be a fork as well. Suddenly, you can't use that GPU with a Rust-implemented filesystem, because you have to pick one of the forks, or you have to make your own merged kernel from the two.
"Just fork it" doesn't work here. It's a logistical nightmare.
Talk about aggressively missing the point.
Rust developers are promising that rust in the kernel should have no impact on c in the kernel.
If rust in the kernel has no impact in c then you should be able to remove the rust from the kernel and move it to it's own project, since it will have no impact on the c either way.