This has been requested before, but I still don't think this is a good idea. (Similar requests using inotify to make all file changes instantaneous have been made as well).

The problem is one of atomicity: installing something into systemd usually consists of creating/editing not only one but multiple unit files, and creating subdirectories as well as symlinks. Since doing these changes all in one atomic step is not possible it is problematic doing reloads at arbitrary points in time since systemd then might see some changes applied and others not. This can result in various problems: for example services showing up multiple times or not at all.

By making reloads explicit and controlled by the user we avoid the problem as far as we can: as it is the admin who executed the operation at a point of time of his choice we can be reasonably sure that the configuration is in a sane state at that time.

"systemctl daemon-reload" is done implicitly by "systemctl enable" and "systemctl disable" since the latter commands each execute one change transaction anyway. However start/stop is something that is frequently done implicitly in the background where the admin does not expect this, so we cannot do this there.

Sorry.

I guess it's not possible to distinguish "internally" when "systemctl start is executed by admin or by other systemd executable, right? :/ In that case, no problem, and thanks a lot for the explanation :)