As long as you can detect if/when you break it, you can then either quickly pick up enough to get by (if it's trivial), or you ask around.
Rust contributions to the Linux kernel were made by individuals, and are very obviously subject to the exact same expectations as other kernel contributions. Maintainers have responsibilities, not “communities”.
Yes it does.
If they completely replace an API then sure, probably.
But for most changes, like adding a param to a function or a struct, they basically have to learn nothing.
Rust isn't unlike C either. You can write a lot of it in a pretty C like fashion.
I think that with all of the Rust's borrowing rules the statement is very iffy.
Most of the things people stub their toe on in Rust coming from C are already UB in C.
For a given rust function, where you might expect a C programmer to need to interact due to a change in the the C code, most of the lifetime rules will have already been hammered out before the needed updates to the rust code. It's possible, but unlikely, that the C programmer is going to need to significantly change what is being allocated and how.
While Rust in the kernel was experimental, this rule was relaxed somewhat to avoid introducing a barrier for programmers who didn't know Rust, so their work could proceed unimpeded while the experiment ran. In other words, the Rust code was allowed to be temporarily broken while the Rust maintainers fixed up uses of APIs that were changed in C code.