I mean sorry but that's just not realistic. What happens to that code if those maintaining the bindings/wrappers suddenly get a new job, or get tired of doing the work? It's nice (in some ways) that they've offered to maintain the Rust bindings, but it's always the maintainer's code at the end of the day.
End users don't care if an FS driver is written in C or Rust, they do care if it doesn't work in a release. It's the maintainer's problem because if they break a Rust module and nobody is around to fix it they either fix it themselves or revert their changes, those are the only two options. That's basically the one hard rule Linus has - no breaking userspace.
This is the case for everything in the kernel, by accepting a module or new driver the subsystem maintainer is committing to updating it as the internal APIs change, that's why there's no stable API. They're not going to be happy to allow modules and parts of their subsystem to be written in Rust just because others are promising to keep it updated, there needs to be a plan for how the maintainers can do it themselves and convince them to be willing to own it. IMO that's the only path forward.
> unless you view the Rust folks saying "hey an email when you break stuff would be nice so we can fix it quickly" is extra work.
What happens if they come back and say "that's too much work for us to fix in time for the next release"? I'll reiterate again that stuff being broken in a release is not acceptable, it doesn't matter _why_ it is broken.