Regarding #2, eliminating context switch overhead and system call latency by running everything in one address space would be huge for some applications. Enorm

Regarding #2, eliminating context switch overhead and system call latency by running everything in one address space would be huge for some applications. Enormous effort has been spent to allow HPC applications to talk directly to the network interface hardware without going through the OS (for instance using the Infiniband verbs API), because system calls are way too slow. This puts a lot of burden on the hardware vendors, because hardware implementation bugs might expose security vulnerabilities that could be exploited by malicious software, and there's no OS layer in between to sanity-check the hardware commands. If a system call is just calling a function, then that's not an issue anymore; you can just use system calls for everything, because it's fast. The compiler might even inline them. The OS can insert any sanity checks it wants and expose a safe API to the application. Regarding unsafe code, it's true than unsafe code blocks can violate the memory safety of the whole system, but that doesn't mean you can never use them, it just means that you need to use them carefully. An unsafe code block could be treated like kernel code or a setuid root binary. In a language like Rust, ideally many of the unsafe code patterns would be migrated into the standard library with a safe interface, and the unsafe low-level hardware interaction that the OS would need to do would be another set of unsafe code blocks. Normal application could be forbidden from using their own unsafe blocks (unless the superuser says it's okay), but they can still call into the kernel and into the standard library. (The way I imagine this working is that the operating system would have a policy of not executing any code that wasn't compiled by a trusted compiler, with compiler options dictated by some security policy. Code that was compiled on an un-trusted compiler can run inside an emulator.) If having unsafe code blocks anywhere in the system seems wrong, consider that operating system kernels are essentially large unsafe code blocks. If we can abstract out the bits that truly need to be unsafe and write the rest as safe code, the end result may be far fewer corners for memory corruption bugs to lurk in, and an overall improvement in security and stability.