As for your concern about code quality, it's the exact same situation that already exists today. The maintainer is responsible for his code, not for the code that calls it. And the Rust code, is just another user.
As for your concern about code quality, it's the exact same situation that already exists today. The maintainer is responsible for his code, not for the code that calls it. And the Rust code, is just another user.
What if you're in a world where Rust code is either a significant or primary consumer of your interface ... surely as the API designer, you have to take some interest in how your API is consumed.
I'm not saying you become the owner of Rust bindings, or that you have to perform code-reviews, or that you have veto power over the module .. but you can't pretend Rust doesn't exist.
C maintainers who don't care about Rust may have opinions about the Rust API, but that's not the same thing :)
There are definitely things that can be done in C to make Rust's side easier, and it'd be much easier to communicate if the C API maintainer knew Rust, but it's not necessary. Rust exists in a world of C APIs, none of which were designed for Rust.
The Rust folks can translate their requirements to C terms. The C API needs to have documented memory management and thread safety requirements, but that can be in any language.