In principle, PID 1 in a UNIX-like system only needs to run one process, then reap any orphaned process exits that come up, and somehow pass the PID and exit information to that one process.
The first variant of this in my mind is to spawn a single process, with a pipe from init into that process, then supervise it and restart it if needed. Orphan exit information gets written to the pipe. That process, in turn, could be the root of any other fancy features like service supervision and so on.
A more extreme version doesn't even need to supervise any process. The most minimal distillation can just execute a command once at start - then execute that same command again whenever it reaps a dead orphan, with the exit information as one or more extra arguments.
Of course this is probably maybe taking the minimalism too far. It's notable that s6, runit, and perp all put more logic than that into PID 1.
The obvious problem is that everything I just described adds overheads.
In all of these cases, the whole philosophy and benefit of this is undermined unless you pass the reaped orphan information in a human-friendly form, so there's some stringification and parsing overhead. Although... I think the stringified form ripples far in this design, without ever needing to be parsed, so that most code is just dealing with process identifiers as opaque byte strings, which just happen to be readable as integers when a human looks at them.
The first version needlessly takes a round trip through a pipe to handle any reaped orphans, which is an overhead that at a minimum you pay for the worst-case service supervision path - when the supervisor dies and then the supervised process dies. A reliable wills implementation - as reliable as you could get in userspace at least - would also have to go through this path in the worst case.
Of course a pipe between two processes could be easily and safely optimized to a futex and a shared memory mapping, but you still have to context switch between processes.
The second version seems at a glance like even more of a toy, with even worse overheads. It takes system call overhead to fork and execute a new process on each PID. It takes overhead to convert PIDs to and from a form compatible with command-line arguments. If you fire off a process each time you reap, then you pay overheads to save and load any state externally. Though there is a certain elegance and power to all this state being stored in the file system - imagine the manual debugging and introspection potential.
But a possible redemption I see here is that once you know what functionality you want to go to production with, even the second version could actually be optimized by rolling the functionality of both this most-minimal init and the command it invokes and the external state-saving into a larger binary which runs as one process, and if you want to keep the file system view of the state you can expose it as a virtual file system mount.
One last negative: forking and executing does create surface area for problems where none previously existed. By definition, those system calls can fail - maybe not in practice in this context, especially if you carefully set up process resource limits, but in principle. Then again, a basic function call compiled down to machine code can fail too, we just pretend it can't - for example if you overflow your stack, or because you ran it on an older CPU or from a corrupted binary and hit an illegal instruction, or the CPU overheats. So in all cases we could - and maybe for an init system should - ask ourselves what is the right behavior in such cases. Going through a fork and exec just forced us to see it.
I suspect there is something elegant and powerful in this design direction, and I know for sure it would be a great learning exercise to try to build a system that boots to a usable state based on something like this. This idea has been rattling in my head for some time... and maybe these bits of vision - state as a file system, ability to optimize it down to one binary and process later, and the analogy of fork+exec errors in this specific use-case to inescapable lower-level errors... that feels like maybe that's the last pieces I need to confidently start tinkering.
