Parts of the linux kernel or glibc or any other critical C code gets replaced by rust code little parts at a time, which is also calleable from C (https://doc.rust-lang.org/book/ffi.html)? That way these libraries could be made safer in a controlled and incremental manner.
And to reiterate I'm asking for technical limitations, not political or dogmatic.
For some projects this isn't a problem. For example, Firefox is replacing bits of itself little by little with Rust, which is fine because Rust targets all platforms that Firefox is built for (though it did take some wrangling to get Rust working on Windows XP). However, a project like glibc is used across a much greater variety of platforms, and many of those platforms may have nothing but C compilers. And those C compilers may very well be buggy and nonstandard, so even transpiling to C won't help unless you're willing to hand-tweak the generated code.
You can't just pass a Vec<> to some C code and expect it to work. The reality is that you're going to end-up writing a lot of C-like Rust - Which either acts on C types directly or converts them to Rust types and then does things to them and converts them back. Either way, the safety is largely lost due to this because C types are not going to be safe.
You also can't use any inline C functions or preprocessor macros in your Rust code, meaning that the interop between C and Rust isn't really that good - FFI lets you call functions, but functions only make-up a part the C API. The rest would have to be duplicated in Rust and kept up-to-date, which is a huge development burden and very error prone.
And when you're finally "done" and all the C code is gone, what you're left with is just a lot of C-like Rust, communicating with each-other through the C API using C types with unsafe code everywhere. Essentially C but in Rust form. You'd have to do a ton of refactoring to turn this into anything like idiomatic Rust, and you can't do that refactoring till all the C code interfacing with that Rust code is completely gone so you can stop supporting interop with C.
The bottom line is that it you could do it, but it won't work well because it's missing the big picture - If you don't write Rust code like Rust, then you don't get the safety guarantee's, and you can't do that if you're trying to recreate a bunch of C interfaces in Rust. C interfaces are not safe in the way that Rust would want them to be safe. It's the same reason why you can't write a converter to convert from C to idiomatic Rust - You have to design the system differently to get the gains from Rust, which is a non-trivial thing to do. Rewriting small parts in Rust isn't going to result in the design differences that you need, and the interop between Rust and C isn't very good, leading to lots of problems while you're dealing with both languages in the same code base.
https://www.youtube.com/watch?v=2BdJeSC4FFI is a further exploration of this idea and how it works. Yes, you do need that small layer, but future libraries will make it even easier. There's the Neon work, for example: http://calculist.org/blog/2015/12/23/neon-node-rust/
What you need to understand is that almost 100% of engineering is economic. Is it worth the time to rewrite things in a new language, to rebuild the tool chain to make things easy/convenient, to deal with the gotchas in each new language and their compilers ? On and on the list goes. And most of the issue is there isnt incentive, users of free software have a first mover problem in that if someone else pays for the software to be made, nonparticipants get it for free. Thus we all wait for someone else to pay for all the wonderful things that would benefit us all.