I didn't downvote you, but I think you have a misunderstanding of a couple of things that are clouding your judgement: (1) the sheer size & inertia of the Linux kernel; there are tens of millions of lines of code, and even thinking about integrating another language will take time- lots of it; and (2) the distributed nature of its development and the diversity of its engineers; the community is not one that can be brought into an auditorium and made to change direction on a dime. Rust may have been around for 10 years, but no one was going to go all in on day one.
Further, this attitude of "Rust is clearly superior, so what's the holdup" is itself a holdup. You can't expect people to just spend their time learning a new language just because it's there, especially professionals with personal lives. These people do serious work, on a codebase that millions of people around the world, including virtually every tech company, relies on in some fashion. That's not a game. It's "serious business."
Serious business doesn't just chase something because it's new and hot and solves a certain class of problems (while simultaneously introducing its own set of problems).
Nothing is a panacea (yet, I suppose). This ship has been sailing for 30+ years. So many millions of man-hours have been put into it that people are justifiably cautious.
Now, all of that being said, I read the DMA maintainer's comments a few days ago and I thought he was being unreasonable, however, he is correct about the external dependency on his code. Even if the Rust DMA wrapper is kept completely separate, under a separate tree, he would still have to contend with the fact that any changes he makes might influence that wrapper and all the code that depends on it. So now, even if they claim to maintain the wrapper 100%, he is still beholden to all those downstream developers that rely on the Rust DMA wrapper's functionality, because if he breaks their code, he knows it'll cause a shitstorm. It's easy to say you'll maintain something 100% and the upstream guy doesn't have to worry, but time passes, things change, and all of a sudden, his hands get tied because it'll impact too many people. That's just reality.
Truth be told, I would eventually suspect some (or maybe many) Rust developers will migrate to a new project, because the rate of change is not going to be fast enough to ever satisfy them. And that's understandable. People want to make an impact, especially when contributing to an open source project (and doubly so on an unpaid basis).
Unfortunately I don't think Redox is the answer. UNIX and its clones/derivatives have had a long run, but anyone who wants to create the next big thing is not going to want just another clone of UNIX, even if it is in Rust.
We have seen the enemy. We understand the threat models and know far more about virtualization, containerization, sandboxing, etc., just by virtue of having had to dogfood these technologies for the last 25 years.
The next big thing (if there is one), will likely be something more like a cross between the Windows world (where ACLs rule the roost, and centralized management is built-in), UNIX with its CLI focus, process composition & command familiarity, and something like L4 which has unforgeable capabilities built in and a formally verified kernel.
Or we'll just go back to a modern day version of the UNIX wars, lol. Something, something about history rhyming.