Comparative directions: where the influences point next

The finding, up front

Plan 9's per-process namespace + uniform file protocol (9P) is the standout. It's the one idea that would unify mechanisms Ouroboros already built piecemeal — the fsd/cond server protocols, the capability send-mask, per-task memory isolation, delegation — into a single coherent design, rather than piling on a new feature. Everything else is either already absorbed or better sequenced behind it.

First, recalibrate: what Ouroboros already absorbed

This has to come first, because the older influence notes were written when Ouroboros had "no fault isolation of any kind" and "one program, hardcoded" — both long since false. The classic microkernel checklist is largely done:

• MMU-enforced per-task isolation plus grant/safecopy bulk transfer — MINIX's sys_safecopy capability-copy model, enforced.
• Synchronous sendrec-shaped IPC (MSG_CALL, sender-filtered replies) — MINIX's IPC shape.
• Server supervision — a registry that restarts a crashed server from a kept image, a passive heartbeat for a runnable wedge, an active ping for a blocked wedge. MINIX's reincarnation server and Helix's self-heal pipeline, in miniature.
• A capability model — a per-slot IPC send-mask, extensible at runtime by delegation.
• Two real userland servers reached over IPC: the FAT32 filesystem (fsd) and the console (cond).

So the interesting question is no longer "what basic microkernel feature is missing." It's "what different architectural idea would take this somewhere new." That reframing points hard at Plan 9.

The standout: Plan 9's namespaces + a uniform file protocol

Plan 9 rests on two ideas: a per-process name space and one message-oriented file protocol (9P) that every service speaks. All I/O — files, network connections, process control, the console — is file operations on named objects, and each process composes its own private view by mounting service trees into its namespace. Crucially, a mount affects only the namespace of the process that made it: no global state, no special permission. The striking part for this project is that Ouroboros has independently reinvented the pieces Plan 9 unifies, but in bespoke form:

Adopting the Plan 9 shape would deliver three things at once:

1. FSOP_* and DSPOP_* collapse into one protocol. Every server — and every future one (a network stack, a synthetic /proc) — becomes reachable through the same walk/open/read/write/stat verbs, no new ABI per server. "Everything is a file" becomes less bespoke code.
2. The namespace becomes the capability mechanism. Plan 9's sandboxing is namespace restriction: you can only reach what's mounted for you. That's a cleaner statement of the capability model Ouroboros built by hand — and the transitive-delegation gap at the top of the roadmap frontier becomes Plan 9's bind. The hard capability problem and the naming problem are the same problem in Plan 9.
3. It subsumes several roadmap items — general delegation, a VFS indirection, multi-filesystem support, program composition — into one mechanism. In Plan 9 the namespace is the VFS.

Honest scoping: this is a large milestone (a namespace table per task, a 9P-ish protocol, mount/bind syscalls, rewriting fsd/cond as 9P servers), and the distributed half of Plan 9 (9P over a network) needs a network stack that doesn't exist. Take the local half now, defer the distributed half honestly — the local half is the coherent next architecture that makes the system feel designed rather than accreted.

The rest, ranked by fit

• MINIX's VFS / a real init + boot image. An INIT.CFG naming a list of programs plus an init task that starts and supervises them — a small step now that spawn/wait/supervision exist. (Plan 9 namespaces make the VFS part moot — the namespace is the VFS.)
• Helix's hot-reload with state migration. Ouroboros restarts servers statelessly (re-derive from disk). Live replacement with state hand-off matters for the first stateful server (a future network stack with live connections), not for fsd. Remember the shape before building one.
• A unified poll/select event model (Linux and Plan 9 both). Blocking is single-reason today; a task can't wait on several sources at once. Real the moment something multiplexes (keyboard and a pipe); premature until then.
• Helix's mechanism-vs-policy vocabulary — worth adopting now as language, even without code, to hold future EL1-vs-EL0 decisions to and resist the split happening by drift.

What to skip (cautionary)

• Plan 9's network transparency / distributed 9P — the local namespace idea is the gold; the remote-mount half needs networking. Don't let the full vision pull in that dependency prematurely.
• Linux's monolithic model — cgroups, the in-kernel driver model, the syscall surface: antithetical to the microkernel direction. The one Linux idea worth stealing (the fd/VFS abstraction) is done more cleanly by Plan 9 anyway.
• Full POSIX fork — needs copy-on-write address spaces; spawn (fresh image, no shared parent state) is the simpler, better-fitting primitive here.

Recommendation

The Plan 9 namespace + uniform-protocol direction is the one genuinely interesting architectural move left: it unifies fsd, cond, the capability model, and delegation into a single coherent mechanism, and it's the natural next architecture given everything already landed. If a single next big milestone is wanted, this is it — and general capability delegation should probably be designed as the namespace/bind mechanism rather than as a standalone send-mask extension, since Plan 9 shows they are the same problem.

The full note, with sources linked throughout, lives in the repository as research-directions.md.