>>14
The default executable format would store bytecode, which would be compiled before execution, and the executables would also double as libraries, that is a paint executable would also expose functions for image manipulation accessible from other executables.
Let's see, Java and .NET are bytecode based, and can do JIT or full compilation if needed (results are large, but if you compare it with other full-fledged implementations like SBCL, sizes aren't really that huge on average). Executables can double as libraries on Windows, as long as there's relocations, and if they don't there are ways to make them act like libraries or have them execute code. When it comes to .NET and Java, they ALWAYS can double as assemblies/libraries. So I can load an exe in another exe, if I desire to do so.
And I'd probably end up making the language very Lisp-like.
Some CL implementations do actually have extensions which make them very reflective and a few of them allow traditional loadable libraries... (But, almost all have some FASL support, which is similar to per-file compiled modules)
An OS based on a reflective OO language with an Erlang-like actor model.
So far, I wonder why would it need to be designed as an OS? Almost everything is buildable on top of modern OSes. Although, if you wanted low overhead, making your own OS may be a good idea.