So they would work on systemd then? Since it is set to have a far larger customer base in the near and long term than most independent cache resolvers (just see the list of distro's who have taken it up).
> Instead systemd is going to end up repeating all the same mistakes BIND has made. At least BIND has a substantial head start over systemd-resolved.
Potentially. But I don't think you've successfully shown that that is inherently due to systemd's design, complexity, or componentization. Instead it is likely due to systemd's relative immaturity of a codebase and that as discussed previously most cache resolvers have had a checkered history of security issues (and assuming systemd is "as bad" as everyone else, it will have security issues).
Is the systemd project passionate about DNS? Is the curl team passionate about protocols and files? Is the opensmtpd team passionate about e-mail?
I think two of the three are yes answers. The great strength of UNIX has always been people's ability to flock to places where their passion is shared and improve and learn (institutional knowledge) about their passions.
I don't think systemd will have passionate people for these extra services and it seems they don't have the institutional knowledge that others have gained since this is not a new kind of bug.
Tons of projects with a single focus have had countless security problems, some so bad the entire project was completely scrapped.
So the entire argument is based on a flawed premise.
Take DJB. He's an expert and djbdns has a stellar security record. He's not going to spend his time trying to make systemd's resolver secure. Instead systemd is going to end up repeating all the same mistakes BIND has made. At least BIND has a substantial head start over systemd-resolved.