This whole debate saddens me

As soon as you say you want to have good logging for your daemons, that is to say their stdout/err and syslog are all captured to the system log and not to some arbitrary tty, you need logging integrated, in some significant way, with PID 1.

Specifically, the very first thing PID 1 must do is start another process to be the other end of all those logging FDs init will create when it starts spawning daemons. During spawn init arranges to connect stdout/err to a socket where the read end resides in the logger process.

Of course, this now creates state in the logging process, it has all these FDs that cannot be recreated, so it can never die, and is essentially tightly coupled with init. You certainly don't want it to be something complex and network facing like rsyslog or otherwise.

Also since this PID 2 must be started before anything beyond tmpfs can be mounted it can't reasonably be any sort of already existing syslog daemon, none are suitable to run in that sort of environment.

So now we have a consolidation and storage requirement for our PID 2, which gets us pretty close to where systemd is. There are various small trade offs here and there, but the integration of the two is not one of them.

Give up the special logging arrangement and you have to give up universal stdout/stderr capture - which is a huge long standing defect in sysvinit.

As an aside, the scheme I talked about above actually does work like this, the log collector PID 2 is fairly simple and only writes logs to structured binary files. Other tasks like syslog delivery to a remote host are done by 'tail -f' on the binary log files and never interact with the logger process. Why binary? To do the async tail -f for syslog purposes we need to have a robust cursor mechanism to iterate asynchronously over the log data, the binary format is essentially the length, line number and then data. Having a unique line number allows us to construct a reliable cursor.