For example, why do unit definitions have to be actual files on disk? Then, all of these files are reloaded when the daemon reloads, not just changed ones. But, why couldn't there be an API letting me add units programmatically? (There kind of is but it's constrained/inflexible)
Or, why can't I declare multiple units in the same file? It's really designed around the filesystem instead of abstracting at a different level, which is a choice I don't think is smart. It's not like it follows the unix philosophy though.
As for the format used for unit definitions, I wish TOML had been around so they could have had something sensible...
https://www.google.com/search?q=systemd+add+units+programmat...
You can do it either via the CLI (systemd-run), or via the D-Bus API (StartTransientUnit).
SystemD has no dearth of programmable options.
I have tried available options including generators.
that and cron always felt fragile too with a lot of quirks and limitations you had to work around instead of being a robust thing from the start.
First it caused lots of issues. And didn't deliver anything significant
But the biggest issue has always been architectural, the way systemd keeps absorbing existing projects, and functionality. That keep adding to the more than 1 million lines of C monolith, that can burden progress in the futre
But as long people can replace any of systemd tool, for a tool they like better, all good
Personally I am now using desktop/server distros without systemd, and there is nothing that I miss, everything works... cuda/llama.cpp/steam/docker...
And commands always have to google them anyway, or find in history...
I have done scheme all my life, which is why I prefer shepherd. Not only is it in a syntax that i can use elsewhere, I get completion in Emacs.
Systemctl is OK, but I really do not like that respect of the utilities.
But that's because I'm old because obviously systemd-* is the only right way and everyone else who see things differently is a pundit.