How Debian managed the systemd transition

So what? If you start SIGKILLing random system daemons, you can't really expect your system to do very well. This is solidly in the "doctor, it hurts when I do that" category.

Interestingly, it can (sort of).

If you do an exec() and it fails from some corruption of the page tables, or the executable at the wrong time without going through the file system (since you get -ETXTBUSY when trying to do anything with an executable file while a process is mid-exec on it), then the process is killed with an inescapable SIGKILL.

This is relevant for systemd, as there's a few circumstances where systemd will exec.

1. When shutting down it exec's systemd-shutdown, which primarily exists so that PID1 isn't holding files open and preventing a clean unmount.
Though a failure here is unlikely to ruin anyone's day too badly, since they were already shutting the box down, they just get a mystifying kernel stack trace on shutdown in the rare case where exec fails.
2. A suitably privileged user invokes `systemctl daemon-reexec`, which instructs systemd that it should serialise its state and exec itself again.
This is so that after a software update, systemd can use the new versions of dependent libraries, rather than the old ones that may have been removed, but systemd would still be holding open.
3. Privileged users may also request a `systemctl switch-root`, which is primarily intended for the initramfs transition, but could be used to move your rootfs to different storage (so long as you don't mind that most of your processes are killed).
In this case there's few processes hanging around to be able to break the executable mid-exec, but systemd supports the notion of "storage daemons", which are processes explicitly out of systemd's control, and are expected to have been exec'd from the initramfs.
If you are using a storage daemon to run a fuse-based rootfs then it could easily corrupt the executable mid-exec.