Part of the problem with that approach is that you're still reliant on the host OS and have just pasted a new layer of abstraction over the old one. Kinda like the web. You haven't really fixed any of the problems of the underlying platform, while at the same time you've added complexity and bloat.

I think there is, perhaps, value in a middle ground. You could take the Linux kernel (chosen here for its existing driver support, openness, stable syscall ABI, and presence of virtualization and namespacing features), but throw away basically everything on top of it and build a new "operating environment". Then, over time, you could fork the kernel away, ditching legacy syscalls and features, maybe creating a stable driver ABI finally, etc.

> The Lisp-all-the-way-down part doesn’t seem as useful as it was originally. You could get 80% of the functionality with 10% of the work of a full OS.

You're missing the point. If the only goal was "functionality," a quick-and-dirty hack on top of existing systems would suffice.

However, the GP wants a system that's reasonably comprehensible all the way down, so he can have some confidence that it's not working against him in some way. The accidental complexity of decades of legacy software works strongly against that.

I completely agree with you, which is why my highest-level comment in this thread suggested using a new ISA, too. However, for practical reasons, it would be a ton of work to design and build hardware and a complete operating system. That’s the holy grail, of course, but it’s going to be hard to achieve without a large company backing it up.