A solution to what? Aside from details of the implementation, one can also disagree with the framing of the problem and scope of the solution. Sure, we're free to implement an alternative solution for doing DNS resolution and IPC and logging and time synchronization and job scheduling and service monitoring and ... but should there be a single solution to all of these things at once?
All of the things you mention are interdependent, as resource and service management is the core of it all. I'm convinced that they set out to design somethign that has a scope which is as small as possible, but then noticed that interfacing with legacy-but-established open source software was extremely difficult.
I'm very thankful for systemd covering more and more bases because the "common" alternatives for many problems might be stable but they are often really bad to configure, maintain and debug - the ergonomics in non-default use cases have a lot of potential for improvement. And what can you do if the maintainer is not responsive to the kind of improvements you would need to make the software ready for the next decades? Many times I have forked things and tried to refactor their technical debt so a new feature can be implemented without making it an even bigger hack, and after that you just want to delete it all and start from scratch with a "proper" setup.
So I can understand the perspective of the systemd developers and the pain they had to go through simply on a technical level, not even thinking about the huge flamewars on mailing lists with some people.
Open source has big social dynamics, and a certain type of person is attracted to being "leader" or maintainer even though they are not as technical as I would wish them to be. I've had the painful experience with having to explain security vulnerabilities to some of them and my idealistic illusion of open source project governance received a good grounding in reality.
On top of this imo the documentation of systemd is really good.
It's literally not a single solution. systemd isn't a piece of software, it's, like, 20 pieces of software.
People who think the init system is doing all of this have just not done even the bare minimum amount of research on the topic. Although, granted, the naming might not help.
Right, I guess I shouldn't have edited out my preemptive response to this: Of course the solution is internally composed of different parts. Most things are. People of course understand that those internal parts could be switched out for new parts that perform the same role in the overall solution, but that doesn't help when the disagreement is about the scope and purpose of the entire solution.
