All major C compilers are written in C++ nowadays.
Apple OSes use C++ for device drivers, GPGPU programming and their compiler infrastructure.
Google OSes use legacy C drivers for Linux and everything else is a mix of C++, Java, Rust, using micro-kernel like architecture where each driver gets their own process.
On Windows it has been long considered persona non-grata and everyone advised to either move to C++ or adopt Clang (also provided via VS installer) if they insist in using C. VC++ only supports C to the extent required by ISO C+++ compliance.
One of the reasons OpenCL lost to CUDA was the initial refusal of Khronos to offer similar C++ tooling, making many researches jump to NVidia.
You say this as if it is the fault of C. I see it the other way around -- Microsoft's refusal to implement C11 is singlehandedly contributing to the decline of C, because they've leveraged their large OS market share to make it impossible to use an update of the language for cross-platform development. They are killing it on purpose, and it's infuriating.
Anyone that wants a C like language with better security has decided that the only path forward is to either ditch it, or impose hardware memory tagging (which Google is imposing on as of Android 11).
Microsoft still supports C in its Checked C variant and just like Google, Oracle and Apple on their platforms, its hardware hardened Azure Sphere Pluton runtime.
C was already on decline in the late 90's, all major desktop and mobile OSes were being written in C++, BeOS, Symbian, Windows with OWL/VCL/MFC, OS/2 with CSet++, Mac OS with MPW/PowerPlant, game developers were moving into C++ with Watcom C++ and PSOne devkit, it was the rise of FOSS UNIX clones with the FSF manifesto to use C as much as possible that changed the wind, thankfully that course has been finally overturned.
The decline of C in an always connected computing world is done by WG14's lack of action.
Embedded C++, and the kernel is pure C.
And as of Driver Kit introduction, 100% full C++ is now an option.
In a couple of years from now, when the full transition of kernel extensions to user space modules is complete, the kernel will be the only C piece left.
Which Apple most likely won't bother to rewrite due to the historical baggage of mixing BSD with Mach code that probably no one is willing to re-write.
From what cursory knowledge I have, Rust maintains both a bare bones standard library suitable for embedded work as well as a more fully featured standard library that is built on top of that minimal library.
What features would keep Rust from becoming a new C other than possibly some issues with ABI stability that from my understanding people are working to resolve?
Unfortunately, it is not. C++ is certainly too complicated, that's why it failed at replacing C, and that's why Rust will fail at replacing C as well.