The 'job model' is the wrong abstraction, as is the unit concept which tries to reduce things that have irreducible differences. I'm also rather amused how you're conceding that they're doing a "bad job," but still shrug it off as better than nothing. If you're offering a mediocre solution to an "impossibly large scope" of a task, then you ought to rethink things. Even then, a poorly implemented feature can be worse than none at all.
I would also point out OpenWrt's procd as an example of how to have hotplug-capable service management at a fraction of the complexity: https://openwrt.org/docs/techref/procd
Now, this rethinking did indeed come with HAL, when the idea of a master daemon and ad-hoc service manager reacting to hardware state changes was unanimously rejected by the Linux patriciate as wrong. Perhaps with systemd they will one day reach the same epiphany for system and user services. Either way, I'm not terribly personally invested in this anymore -- I just figured I'd wrap my thoughts up on an issue that occupied a good deal of my time years ago.
So far as prior art is concerned, see my old post: https://blog.darknedgy.net/technology/2015/09/05/0/
I would also point out OpenWrt's procd as an example of how to have hotplug-capable service management at a fraction of the complexity: https://openwrt.org/docs/techref/procd
Now, this rethinking did indeed come with HAL, when the idea of a master daemon and ad-hoc service manager reacting to hardware state changes was unanimously rejected by the Linux patriciate as wrong. Perhaps with systemd they will one day reach the same epiphany for system and user services. Either way, I'm not terribly personally invested in this anymore -- I just figured I'd wrap my thoughts up on an issue that occupied a good deal of my time years ago.
EDIT: As to B, the problem of process supervision and having an idiomatic way of daemonizing has been solved for a long time: https://jdebp.eu/FGA/unix-daemon-design-mistakes-to-avoid.ht...