Regarding #systemd, #LWN summed up comments by Luca Boccassi:
> The systemd v258 release took about nine months of development.
>
> Boccassi said that "everybody was unhappy" with the long release cycles,
> so the project decided to try to do a release every quarter. "We have two
> months of merging features and then one month of stabilization and
> release candidates."
Which leads me to why no-one questions that an init system needs 2 months of new feature work 4 times a year.
init is not a complicated set of requirements. See e.g. https://skarnet.org/software/systemd.html by the author of #s6, also https://skarnet.org/software/s6/s6-svscan-1.html
A proper, functioning #init for Linux (and other platforms) should not be an endlessly growing pile of (slop-assisted) code and features and system functions assimilated into one baroque, monolithic [1], Linux-specific and unreplaceable [2] software component.
It doesn't need to be in a constant state of churn. We've known what init needs to do for going on 60 years at this point. Yes, there's some evolution over time, but init should be damn well *done* by now. Everything else that gets thrown into the systemd kitchen sink should be, and traditionally has been, done by independent, replaceable components not running as part of the init system.
[1] Note: *functionally* monolithic. It doesn't have to be in one executable file. See https://judecnelson.blogspot.com/2014/09/systemd-biggest-fallacies.html for one explanation.
[2] As opposed to "irreplaceable".