Exactly. No one is saying "rewrite it in Rust because it already works". They typically say it because the thing in question is a bug farm, or it's really difficult to maintain.
I looked for the author's (whoever they are) proposed solution and it's this:
"This is because many of the FFI bugs surveyed are fundamentally cross-language issues. Instead, we propose that both C and Rust must conform to a shared,
formally-based domain-specific language, which provides a safe-by-construction abstraction over the FFI boundary."
Such a thing is a "new thing", and isn't going to retroactively apply to the legacy C code written before this new thing... so how does that help?
(Full disclosure: I'm a professional programmer who has written in C, C++, C# for many years, and now I choose to write new things in Rust.)
I looked for the author's (whoever they are) proposed solution and it's this:
"This is because many of the FFI bugs surveyed are fundamentally cross-language issues. Instead, we propose that both C and Rust must conform to a shared, formally-based domain-specific language, which provides a safe-by-construction abstraction over the FFI boundary."
Such a thing is a "new thing", and isn't going to retroactively apply to the legacy C code written before this new thing... so how does that help?
(Full disclosure: I'm a professional programmer who has written in C, C++, C# for many years, and now I choose to write new things in Rust.)