There's always folks suggesting that systemd is too complicated, and that simpler solutions are better. But, I have to assume they've never dealt with the compl

There's always folks suggesting that systemd is too complicated, and that simpler solutions are better. But, I have to assume they've never dealt with the complexity that SysV initscripts leave up to the developer and packager. I don't mind giving that complexity to the systemd developers. The old Apache initscript (for just one egregious example) was a huge ball of shell script wizardry that checked all sort of things on startup, handled restarting/reloading based on the command and some other factors (graceful restart is only possible under some circumstances, etc.), kept up with PIDs, and cleanup. The systemd unit file for Apache is 17 lines long, minus comments; it is declarative, looks like every other unit file, and handles all the same stuff, and better than the old initscript. The complexity is gonna be there. These systems are complex and do complex things. it's just a question of what layer the complexity shows up in. systemd pushes it all down into systemd where most users and administrators and packagers and developers never have to see (much of) it. And, as you note, run levels and process order are another layer of complexity pushed onto the administrators that could be pushed into the init, but never were under SysV initd. Again, it's handled by humans who have to have a lot of knowledge about the system, the service in question and its dependencies, in order to write the initscript and put it in the right place in the boot order...and there's room for mistakes. I've been packaging system level services long enough to have had many experiences getting it wrong in subtle ways.