I'm one of those people who find most systemd opposition rather unconvincing, but good luck to you anyway.
I was surprised by the fact that you'd actually removed the mount and device unit logic from your fork. In my view, the init/service manager (with its dependency resolver) is the correct place for something like that because services depend on devices and mounted filesystems being available. How should those things be handled, if not there? Udev-triggered units and systemd generators seem to me a very clean way of handling the problem while maintaining backwards compatibility with /etc/fstab and other configuration sources.
systemd's purpose is to deprecate fstab(5) entirely through GPT partition discovery.
These things can already be accomplished through a device node manager, such as (e)udev. We just no longer handle maintaining it, because it doesn't belong here.
I don't see deprecating fstab as a bad thing, if it's possible. Less static configuration is pretty much universally good. It's also pretty much zero burden on systemd to maintain fstab compatibility indefinitely.
However, I was asking for specifics. Accomplished how, exactly?
udev can generate an event and run a shellscript or something when devices become available, but... then what? What processes the event and ensures correct behaviour for dependent services?
I was surprised by the fact that you'd actually removed the mount and device unit logic from your fork. In my view, the init/service manager (with its dependency resolver) is the correct place for something like that because services depend on devices and mounted filesystems being available. How should those things be handled, if not there? Udev-triggered units and systemd generators seem to me a very clean way of handling the problem while maintaining backwards compatibility with /etc/fstab and other configuration sources.