Not really, unless it manages to cater the interest of a platform vendor.

As much as I dislike it, fact is that C will stay around as long as UNIX clones, or POSIX implementations exit. So here efforts like Frama-C and Checked C are much more tailored for success.

Then if we look at the OS landscape, we already have a mix of languages replacing C to certain extent.

On mainframes, C was never relevant to start with, so the surviving ones from IBM and Unisys make a mixed use of their original systems programming languages, PL/S and NEWP, mixed mostly with C++. Whatever C like code is used, it is in the context of "compiles as valid C++" still.

On embedded, besides C + language extensions (stuck at C89 in some domains), there are C++ based platforms like Arduino and ARM mbed, microEJ (Java + C), Pascal and Basic (a couple of surviving OEMs are still around), Oberon (Astrobe), Ada, Java and .NET bare metal, TinyGo and Rust are now doing their baby steps.

The relevancy of C on embedded can be shown by Microsoft adopting it as the only language for Azure Sphere applications, despite the whole sales pitch about IoT security. Apparently despite all that talk, the market they are targeting is only interesting in buying, if the platform only speaks C. Currently developer requests for C++, C# and Rust support keep being nicely rejected.

On research OSes we have GenodeOS now going with a mix of Ada/SPARK and C++.

Windows is a mix of C, C++ and .NET, and the market pressure for C has won, as Microsoft gave in to their "you will only need C++ and .NET", and the more recent version of MSVC introduced support for C11 and C17. Most likely also caused by the need to support Azure Sphere and WSL development workflows.

On ChromeOS, only the Linux kernel is C based, everything else is a mix of JavaScript, C++ and Rust.

On Android, similarly, we have C for the Linux kernel and "legacy drivers", everything else is a mix of Java and C++. Project Treble also supports writing drivers in Java if one wishes to do so, and the reason why Google is having meetings about using Rust in Linux kernel is related to possible adoption of Rust in the Android world.

Fuschia uses a mix of C++, Rust and Dart. I think none of the original C code still survives as pure C.

Apple platforms use a mix of C, Objective-C, C++ and Swift.

Then we had experimental OSes like Redox (Rust), Powernext (D), in production hypervisors like gVisor (Go), secure firmware like TamaGo from F-Secure, low level file system drivers like Weka.io (D),...

C++ has gained a new wind on its sails as the main language for GPGPU programming, regardless of used directly or via language bindings. The only thing that might cut it, are better support for GPGPU programming from other languages, or some kind of GPGPU DSLs, then again NVidia is pretty much focused on first class support for C++ on CUDA, so.

Game console SDK are all about C, C++ and now C# (thanks Unity).

So, C replacements already exist, one just needs to step away from C cargo culture that there is no other systems language.

On the other hand, there are domains where no matter what, C will remain the sole king. So we need to fix its warts without throwing away everything.

However, Zig is a welcomed arrival to the party of compiled languages, maybe it will find its niche and make a couple of happier users anyway, even if it never makes a dent replacing C.

That I what I consider a success for programming languages, having their own customer base that keeps the language alive.