What you as well can do is record-replay -- well, at least there used to be this option, I'm now lost whether it has never been merged anywhere, or it is stuck in some PR somewhere. This was truly great - since the external interface is so thin, it is easily doable to dump all external events (API calls and returns) onto disk and replay one-by-one, inspecting the state.
To be a bit more precise, what we achieved so far: apart from web servers and TLS reverse proxies (with DNS-backed let's encrypt provisioning), DNS authoritative servers, a CalDAV server, git client and servers, SMTP stack (including dkim etc.), OpenVPN implementation, archive mirror (using tar as file system), monitoring with syslog and influx, ...
Some MirageOS developers were hired/acquired by docker -- though not the (open source) project, beither the code... There's still quite some work on MirageOS itself, including reproducible binary builds, VPN, DNS services, orchestration solutions, ...
MirageOS is - similar to the latest OCaml release - only using a single CPU core. You can run multiple unikernels, one on each core. If doing that, you can use Xen vchan (shared memory), or TCP for marshalling.
> Also I would say there are reasons for isolation beyond memory safety.
Would you mind to elaborate which reasons you are thinking of?
We use asynchronous tasks in MirageOS (cooperative multitasking) using lwt http://ocsigen.org/lwt/latest/manual/manual, so you can serve multiple network connections at the same time.
Since there are no processes, there's no concept of "fork", but indeed you can run multiple tasks at the same time (using the same address space). Why again would you need multiple processes? Since the programming language OCaml has a semantics and is memory-safe, there's no strong reason for isolation at execution time (apart from the C bits, which we try to keep to a minimum and compile with runtime safety flags (red-zone for stack protection, mapping execute-only (seems to only reliably work on OpenBSD), etc.)).
What you as well can do is record-replay -- well, at least there used to be this option, I'm now lost whether it has never been merged anywhere, or it is stuck in some PR somewhere. This was truly great - since the external interface is so thin, it is easily doable to dump all external events (API calls and returns) onto disk and replay one-by-one, inspecting the state.