But it's not going to be "drop-in", lots of stuff will have to be refactored to work with Rust's memory model.
See, memory management is a hard problem and the complexity involved in solving it has to live somewhere.
In C and C++, that complexity lives in the programmer's head.
In Java, Python, Go, etc. that complexity lives in the program's runtime in the form of garbage collection.
In Rust, that complexity lives in the compiler - with some caveats, Rust code is safe as long as it compiles and passes the borrow checker.
However, the ownership-based memory model of Rust is not always trivial to port other code to. Modern, idiomatic C++ written with RAII and smart pointers should be relatively easy to port to Rust, but most of the critical systems code out there is not like that at all. Most of the critical systems code out there is written in C or old-style C++ with C-style strings & arrays and raw pointers to heap memory all over the place.
So regardless of what your C/C++ language replacement looks like, it will take some serious effort to replace that kind of code.
You can't do "drop-in replacement" and "memory safety" at the same time.
I'm in no way an expert in any aspect that relates to this problem, but it's reasonable to believe that it would be but a mildly challenging task if companies like Google, meta, Microsoft and the likes joined forces.
A year of concentrated efforts might be sufficient to rid us with this problem once and for all. Billions of lines of codes would gain (some) safety instantly.