> don't merge udev, go ahead and enhance udev to provide whatever service you are wanting to use, but keep udev a separate project so that people who don't want systemd continue to be first-class users
It's sort of touched on in myth #10. Separate git repositories is not the only path to modularity.
> don't reinvent syslog, if there is something that you need, contact the syslog maintainers and ask for the feature if you want it. Or if they don't have time to implement the feature, write it and contribute it (all of the syslog daemons accept outside contributions, and rsyslog, the default is very accepting, and supports sponsoring new features if you can't just convince them it's a good idea)
Projects don't own turf just because they provide the current implementation. Contributing to existing projects is certainly a good method when possible, but I don't think you'd get very far asking MongoDB developers why they didn't try to get their changes progressively into PostgreSQL or MariaDB.
> The latest thing with CRON is another example, the argument seems to be that they need to take over cron because it's another way to start a process, and they need to know about all process starts to 'manage' them.
My same thoughts here. anacron didn't integrate their features into cron. Nor did chrony seek to slowly improve ntpd. Nor did git seek to build on Subversion. (And there are many more examples.) Why does systemd have a unique responsibility to improve other implementations rather than providing capable replacements?
> How about instead defining a 'startup' program that starts jobs in their own cgroup, notifying interested programs through some mechanism (init being one of them, but probably not the only one) and then get CRON modified to use this program to fire off the apps.
That sounds like a reasonable capability to me, but it doesn't have any bearing on whether systemd should implement other features like a cron equivalent and the journal.