The problem is less the init system itself, but applications that depend on a specific init system [1] (gnome used to be a major source of contention in that regard).
[1] https://wiki.gentoo.org/wiki/Hard_dependencies_on_systemd
Gnome does not depend on systemd, but rather logind.
KDE used to be the same, until someone started maintaining ConsoleKit2 again, proper, at which point they were happy to support it.
ConsoleKit was dropped because it just wasn't being maintained, and had various limitations.
Maybe it's simply easier to maintain this way?
elogind exists, if you care. It exposes the DBus interfaces that logind supports for applications to call.
Thus, environments like Gnome can be supported on non-systemd systems if they emulate and/or expose and implement the required DBus interfaces.
See also https://lwn.net/Articles/586141
And like I already mentioned in my previous post.. there are other alternatives around than just SysV-init..
By not tightly bundling their init with other OS components, by not having GNOME desktop somehow depend on what init system you're using (as opposed to services running under that init system).
Also you know how shell scripts have `#!/usr/bin/env bash` at the top of them? Well the reason why my hypothetical init system would be compatible with SysVinit is because instead of `#!/usr/bin/env bash` it would have `#!/usr/bin/env new_init_language` at the top of it. 'new_init_language" could implement almost all the same features that systemd unit files do.
Guess what systemd does?
> sets things up, and then exits
And that's the crux of the issue isn't it? Because on modern systems, things need setting up and tearing down all the time.
Well not really, that's an artifact of systemd's over-engineered design. There's nothing stopping you from tearing something down from an init script or doing more complicated dependency management using the CLI as your RPC mechanism (but red hat needed a reason to use their in-house RPC mechanism).
Honestly something like systemd could be pretty reasonable if it wasn't created with the express intent of "combating fragmentation". Not that there aren't a whole bunch of technical and architectural issues with it, but still.
Except most init scripts I've seen are rather brittle and only "work" if the PID dance is exactly as the author predicted, are not declarative and hard to debug.
I don't want to go back to init scripts, for all systemd's faults, the past was worse.
Using the CLI as my RPC mechanism etc. just sounds like I should spend a bunch of time doing work that systemd can do a better job of managing for me.
If I was approaching building an init system I'd make a better language for writing init scripts than bash, some kind of interpreter that processes mostly declarative init files, sets things up, and then exits. An incremental improvement that works with existing systems instead of putting a whole bunch of new (generally un-audited) code into PID 1, with all the security implications that implies.
Redhat may contribute the majority of the work but they're also very good at positioning themselves so that outsiders can't really contribute any work, or get any independently developed standards implemented.