I will definitely be making a post with my findings. Right now I am focusing on understanding the need that systemD fills. Clearly there are a lot of stakeholders involved in system startup (system admins, normal users, distro packagers, even Android), so I am trying to figure out what each of them want before critiquing the solution.
As for systemD itself, it's patterned off of launchD, which I find interesting. You can see
an explanation here. The part I find interesting is how it manages dependencies: you don't have to explicitly list every dependency of a server, but rather when something connects to a service, launchD starts it right then. LaunchD takes advantage of the excellent inter-process message passing abilities of the OSX/Mach kernel.
There are red flags also. For example, Poettering started by converting the build scripts to C, explicitly because it was slow. He said, "grep must get called 70 times in my script. Think how long that must take, accessing disk, loading libraries, etc." This is an example of "the root of all evil is premature optimization." If he'd measured before starting, he would have found that calling grep 70 times takes a fraction of a second (on my laptop, anyway). And indeed, when he was done rewriting everything in C, he was disappointed to find it didn't go much faster.
Also, I think binary logging is moronic, but that's been hashed out in many places and you probably already know about it. Apparently some people like it.
I'm kind of reticent of writing posts as I go along because I may change my mind once I understand the purpose of something, or why something is written in a certain way, but maybe I can put a disclaimer on top that it's a work in progress and don't take anything I say seriously?