The problem for me with such a strict view is the special status of pid 1. You can not have a reliable process manager without either putting it in pid 1, or having restart logic in pid 1, since a process manager outside of pid 1 can be killed without taking down the system, and thus can die unnoticed unless the init includes restart logic.

You also have a second problem: How do you log failures reliably? Your process manager can not do that, or be responsible for spawning something to do that if it itself is pid 1 - it could be brutally murdered the instant it spawns the next process, or at any random time, unable to pass on any temporarily collected data while waiting on a suitable place to store said data.

There's a lot of thinking behind the systemd architecture that actually make substantial advances over what we used to have, and that solves issues that are not at all addressed by most other init systems. Your suggested sinit + svc + perp for example would suffer from both the dead process manager problem and the log problem. They are real - I've run into that more than once.

While I'm not in love with, or convinced by, how much stuff they've added to it, also keep in mind that systemd is not just a pid 1 replacement. The systemd project includes multiple components, only the core of which runs as pid 1.

Maybe it'd be nice and useful to see that decomposed with clear API's connecting them, but for now they're developed and shipped together, and I understand why they don't particularly want to have to deal with that, but seeing systemd-the-project as just an init replacement is not really the case (though pid 1 in a systemd install still contains more than you suggests it should).