I don't see any major reason why Rust couldnt be used for a new "real" OS. The "stdlib doesn't report failure on allocation" stuff isn't really relevant; it's not like people use libc malloc in the Linux kernel. Lack of intrinsic exposure on stable doesn't matter, people will just use the nightlies. Intrusive lists are useful, but they don't require that much unsafe code. Likely / unlikely will be in the nightlies any day now. Performance is already on par with C++ if you care enough; removing drop zeroing will help, though. Only big thing I see missing is unsafe unions.
(If you're arguing that drivers will still need some inline assembly, well, yeah. But the assembly required for hardware interop is pretty straightforward, at least compared to code written in assembly for performance).
"I don't see any major reason why Rust couldnt be used for a new "real" OS."
I'm not saying it can't in principle, I'm saying it would take years to get to a usable point. But then again - I wouldn't mind being wrong here! :]
"I'd be interesting in knowing what their thinking is as well."
OpenBSD is proudly exploiting quirks of various platforms to stress test the code and find cases where differences break the code and expose bugs. Change from C won't happen just because Rust is here to stay. Especially not until LLVM (and preferably musl) runs on most of the platforms OpenBSD runs on. the official stance for LLVM in general is that it'd have to get to the parity with gcc WRT platforms that OpenBSD finds interesting but reality is that a platform or two out of ~15 could be dropped if LLVM provided benefits over gcc. LTS compiler is something OpenBSD (and not only them) would appreciate greatly. But it's not going to happen, I'm afraid.
(If you're arguing that drivers will still need some inline assembly, well, yeah. But the assembly required for hardware interop is pretty straightforward, at least compared to code written in assembly for performance).