I have no doubt that you are correct, but these new insights do not come for free. Much as I love learning new things, I know that my capacity to do this is limited so I need to pace myself. Had I decided to write this project in Rust, I am quite confident that I would not have progressed a far as I have. Sometimes it makes sense to work with what you've got, even if that is "C".

Also, you are making an assumption that is worth highlighting. You are assuming that if some language is problematic, then the solution is to use a different language. I understand the thinking behind that assumption because programming languages have always effectively been isolated silos. But the "replace" approach doesn't always work so well: witness Python 3.

Maybe there is another way. A significant strength of the Linux kernel project is the incremental approach to improvements. Today's kernel is very different from Linux 1.0, but it is still "the same Linux". What if we could do that with a Language? The C standards process does to an extent, and "C11" is still "C", even though it is very different to K&R C. But there a limits to how much change can happen there.
It has always been possible for different projects to use different versions of C, thanks to the macro pre-processor. Having "list_for_each_entry" and similar is the kernel is a real boon.
Having pluggable semantic checks could be seen as just another step in that sort of approach. Why are you so sure that replacing C is a better approach than making C better.
I like the familiarity and universality of C, and the safety of Rust. Why should I not want both?

> It's hard to believe...

I would suggest that the evidence is against you there. My own observations tell me that people are, in general, quite capable of believing whatever they want to believe.
So I think you are really saying "I don't want to believe...". I assure you that I completely support your right to believe whatever you choose, but know that I will likely make different choices.