Here's a good summary of the issue: http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/de...
A bad thing about systemd and where we are now is the ever-changing API that is mentioned, which hampers alternatives to systemd.
But, that is where we are now, Debian isn't in much of a position to change that, and forking probably isn't going to help with that. Debian wasn't ignorant of that either; these issues were discussed at length in the tech committee debate that originally settled on systemd being the default for jessie.
It's big, gnarly, essentially undocumented, and contains a bunch of features to support tricky cases like multiseat machines (systems with two or more sets of keyboard, mouse and monitor, each with a different user) that are rarely used but still need to be supported because the API's designed around them. Even the systemd developers don't think a reimplementation is feasible.
http://dvdhrm.wordpress.com/2013/08/24/session-management-on...
http://dvdhrm.wordpress.com/2013/08/24/how-vt-switching-work...
http://dvdhrm.wordpress.com/2013/08/25/sane-session-switchin...
This I can't wrap my head around, why does Gnome for example need systemd? There are standard ways on GNU/Linux to do everything it needs in a unix fashion (by deferring to small specialized tools):
These and similar tools (or libc functions) give you all information you need (username, etc.) and system functions a desktop environment needs (reboot, hibernate). You then only need something like udev for plug-and-play (which is available without systemd, and as a part of it), and interfaces to the X/Wayland server and the audio system (which are both not a part of systemd). This seems to be all stuff that can easily be abstracted away in one module per OS. I don't see why you have to tightly couple your DE to systemd. (Unless, you are using your DE as a vehicle to push systemd, which I hope is not the case...)