The internals of systemd consists of reams of repetitive string processing that should not even have been written in C, and lots of indirection which obscures control flow paths through the program.
The behavior of systemd is only completely specified only by its obtuse implementation, which was developed by some people who have no clue how to design that kind of thing (or to specify and document it).
Why I even know this is because I had to switch to source level debugging to figure out why systemd is or isn't doing something, and how to change it.
Background: I worked on substantial improvements of Linux's ability to support serial consoles on a USB-serial device. This required interaction with systemd. Part of the functionality is that you can plug a console in before booting or after, and get a prompt. Moreover, you can unplug a device with one kind of USB-serial chip, and plug in a different kind that uses a different driver, yet completely recover your existing session, which could be in the middle of a vi edit or whatever).
To get the behavior completely polished, I had to wrestle with systemd, which was killing the sessions in an obscurely mysterious way that made the USB-serial/TTY/console code in the kernel look like a walk in the park. I think it took me several days to figure out, after poring over the systemd source code. First I discovered it was systemd doing the killing by putting some printk's in the kernel. Reading systemd documentation was useless, so I had to crack open the source code and start instrumenting that. I think it took the better part of a week to finally get the behaviors ironed out.