At least one of each side of the debate. Preferable there should be two, one on each side which implements the good/novel ideas and others where aggressive experimentation takes part.
There aren't actually two sides of this.
There are only in the scope of systemd vs everyone else (just because systemd is something that is pushed as THE solution).
There are multiple solutions that all have their supporters. And we generally actually get along and work together pretty well. BEcause we don't think that one solution is necessarily better than the other in all aspects.
It shouldn't be “provide a reasonable alternative to systemd and then we will compare”. “We” won't “compare” anything. Competition is awesome, “we” shouldn't “choose” just one implementation of anything just because the majority of distros uses it.
It should be “let people do their thing and please don't hard-depend on this one init system or anything else without a really good reason to do so”.
Just to be clear: I know that among the bigger projects it's just GNOME3 that is planning to hard-depend on systemd and even they want a shim, externnal or internal, to accomodate systemd-less systems (not necessarily BSDs, maybe other linux distros too).
Currently systemd is very much optional (opt-out, not opt-in, learn the difference) and I personally mantain an Arch flavour that uses sinit, smdev and a bunch of other small projects while still relying on Arch's package base.
It's the attitude of the upstream that seems like a threat: “we want everyone to use systemd”. And if they succeed, developers of userspace software will be very much justified in hard-depending on it. Who cares if everyone uses it, right?
TBH, I currently feel the same way because of the opt-out, not opt-in situation. On one machine running Debian Sid I just found myself running systemd after an dist-upgrade..blowing my mind considering that I didn't choose Arch in the first place for the rolling release machine because of the systemd. But GNOME3 is to blame making systemd a hard dependency(Even if they mostly seem to be from the same camp, RH).
systemd provides things and does things that are useful. That is why GNOME depends on those. Blaming us? Try actually understanding why. It's not a hard dependency btw, you still have ConsoleKit support. A project not maintained for almost 3 years or so. Then there is that systemd-shim. Initially very very buggy, but now ok-ish. OpenBSD is working on some shim thing as well.
Others working on systemd shims out of necessity is a sign, IMHO, that systemd is in reality a hard dependency in the near future (and developers trying to free from that dependency).
I don't say systemd is not useful, GNOME using it shows also to good sides of it, but others feeling a little forced to choose systemd or The Unix Way I think is the wrong way to do it. Why can't we have both(modern init system and unix philosophy)? Not possible? Not enough interest/resources?
You're conflicting things. GNOME doesn't rely on systemd, it wants an API (a few actually, but AFAIK the only difficult one is the bits from logind). The entire API is hard to implement. The parts that GNOME uses maybe can be implemented by someone else. Maybe not. Someone from GNOME tried to do that for FreeBSD but gave up after a while (problem was the lack of interest, difficulty combined with not being a *BSD person). KDE also will use a small part of logind in case you use libinput as well as Wayland. But again it doesn't rely on systemd, it wants a dbus API.
If someone makes something else, go for it. But API wise it is best to stay the same.
I think you have a much more stylized view of what a side of a debate is than reality suggests is the case. Creating an implementation for a side that wasn't already rallying around one would just exacerbate the differences in opinion on that side and fragment it into multiple smaller sides.