A C API can stay relatively the same if you switch a function to a macro, or make it inline. In a lot of cases you don't actually care which of the options it might be to begin with - the syntax generally stays the same, and the situations where you care (Mostly just function pointers) are somewhat uncommon. Such changes would easily break a simple wrapper though. That said I do see your point - It's not like the C code is guaranteed to work either, so perhaps that is acceptable. The maintainer still has to weigh the disadvantages of supporting a Rust wrapper to the advantages of allowing Rust code.

My original point (which has gotten a bit muddled in the details) was just that there could be room for a language closer to C that offers to fix some of the more annoying issues, while still keeping very good compatibility with C overall and avoiding the need for 'wrappers' and such to interface it with C code.