You can also specialize C code for architectures, you do not need C++ template metaprograms for this. I also see them overused, creating a lot of bloat that then can hurt performance.

Rust has many flaws C does not have, including a type system build on monomorphization, annoying syntax, less explicitness, worse support for independent compilations.

But what you can is put an ownership / lifetime model similar to Rust into C or C++. This does not avoid all the hassle of Rust but would avoid some of the problems of Rust and allow a much smoother transition.

It is the usual problem of open-source and free software. What is old is not maintained properly. Rust gives companies an excuse to move on until it too is boring and old and will suffer from neglect.

For example, cyclone, a predecessor of Rust, was much closer to C

Java, C#, Rust, and Go were not created by people who want to make C safe, but people who have different ideas on how a language should work. Go is, unsurprisingly, close in philosophy but the others are very far.

Function pointers do not need to be replaced in a safe version of C.

You are right that you need something as lifetimes or a borrow checker. You certainly do not need an entirely different syntax, proc macros, monomorphization, many different string types, etc.

It is mostly hard because there are no resources for it. Even for maintaining C front-ends compilers there are barely resources, there is so much which you could do easily, but most of the energy goes into C++ or other things.

I do not think a hardened version of C is that hard. Fil-C is slow because it runs unmodified C. To develop a hardened version of C you need to subset C and emit errors for possible UB. It would need some extensions for ownership and/or lifetimes, but there is no need to throw out the baby with the bathwater and come up with a super-complicated and different language such as Rust.

It would be a subset of C where the compiler emits warnings or run-time checks for possible UB.

Rust is not a hardened version of C. Rust is far more complex than C, not stable, has different syntax, different principles, and very long compilations times.

A hardened version of C would be the way forward, not Rust--.

No, and this is the problem.
void foo(int &);
int a = 1;
foo(a); // in C it is clear a is copied and not passed by reference.

The problem is to ensure proper bounds checking, but this is always required with pointer arithmetic in C. If you do element access for arrays, you can just turn on bounds checking and the compiler will insert checks for you to ensure memory safety. This also works for arrays accessed via pointers.

References do protect against dereferences of null pointers, but those trap (or can be made to trap), so are not a memory safety issues. On the other hand, with references code becomes harder to read as

int a = 1;
foo(a) // what is a?

has a clear answer in C but not in C++.

This "entire application written in C (and C++) is inherently unsafe by design" argument is also exaggeration. Not all C code is unsafe, in a single-threaded C application there are essentially three specific features in C that are unsafe with respect to memory namely pointer arithmetic, union access, and free.This also depends on the C implementation, but typically these are the three features you need to care about and you can easily isolate pointer arithmetic and union access into safe wrapper function. Only to avoid use-after-free this is a bit harder.

I agree there might be cases for rewriting things (it wasn't me who asked). But no recent Rust rewrite I have seen in the open-source world made any sense to me.