I'm no fan of .deb's forced service restarts on package upgrades, especially since they don't help with custom-configured instances. I also find the .rpm approach of staying hands-off inadequate.
It would be great if systemd provided a facility for package managers and scripts to mark services (either individually or with some fan-out pattern to catch multiple instances) as needing a restart to make an update take effect. This is particularly important for security updates, and doing a whole reboot is usually overkill.
Then, ideally, administrators (or, say, Chef) can run "systemctl restart-upgraded" to restart the marked services. Systemd could also allow listing units that await restarts so it's possible to surface the information to monitoring tools and motd.
It would also be good if the flag on a unit allows marking whether the update is necessary for security or not. That way, it would be possible to (1) only restart units requiring a security update and (2) list units pending a restart for security.
Units could also accept configuration indicating they should be immediately restarted upon getting marked either (1) in any case or (2) only when it's a security issue.
Humm, so I don't really believe in this kind of logic anyway. Figuring out what you need to restart is incredibly hard with modern packaging systems, simply because libraries might end up being linked into a tonload of services, and very often even indirectly via loadable modules, hence any attempt to making this possible with such a simple scheme is doomed to be incomplete and hence fail, and create a false sense of stability.
I pretty sure I don't want to add infrastructure to systemd for a feature that is necessarily broken.