I think what replaces C should be something like Nim, which compiles to C and also has great C interop. C++ is definitely not it.
The security track records of nearly all large scale network facing C projects disagree with you.
Nothing prevents quitting structural code in C++. Or even functional for that matter. (Though function objects are not quite light yet.)
There are even safe subsets where at most you will get an exception when you try to do something dirty. Easy to enforce.
Certain things like compile time calculation (being enhanced by the moment) do not even reasonably exist in C or for that matter Nim.
The about one gripe with C++ is ABI or rather lack thereof. Three other is the amount of legacy code written in C or outdated dialects of C++.
In the safety critical programming we use subset of C or (C++) with static code analysis. It's possible to prove that there is no dangling pointers, divisions by zero, floating point exceptions (with assertions), out of bounds array access. It's called verification.
Programming is limited into MISRA C and then it's run trough static code analysis tool like Astree to prove that there is no runtime errors. There are still bugs, but they are not "typical C errors". Waiting for new systems programming candidates to get their toolchain to match the task.
Ada, doing it since 1983.
C has no standard language provided range checks, and pointer security, but the amount of compiler macroses that do the same/coverage tools/runtime security tools/checks provided by compilers is huge.
At least part of "inherent issues" of C that Rust advocates often cite was long solved by these tools long time ago.
They are not a bullet proof solutions to lack of security features in C, but neither are the built in checks of novel languages. The amount of NX breakouts, syscall hijackings, clever tricks around range checks in so called secure languages being demonstrated every year confirms that.