Devuan Jessie beta released

I don't buy the "it still needs to be processed by a turing complete language" argument; that's basically saying that because systemd (the unit file interpreter) could be buggy, you can't reason about unit files. The same argument applies to any sort of restriction - when you allow the browser to interpret HTML for display, the "theoretical" advantage of doing so instead of running an arbitrary binary in supervisor mode doesn't really exist, because a bug in your processor could result in the browser's HTML parsing code being interpreted as instructions to wipe the disk.

And 100 directives isn't that large, compared to the set of bash built-ins, especially since not all directives can occur in all sections of a unit file - if this file does not have (for example) a [Mount] section, all the directives that only apply in the [Mount] section are errors; you thus only need to know about the directives that apply to each section. Plus, systemd provides the tooling you need to generate units from code at run-time, if you really the flexibility - but the fact that you're asking me to review a generator instead of a unit file tells me that you're writing a special case, and I ought to look in more depth at your code output.

There is always going to be some case that you didn't think of when you designed your config. init scripts give you the ability to handle your special case in a way that makes sense to you without having to get a new option defined and propagated to the whole world.

Which is presumably why systemd lets you use an init script in place of a unit file if you have to. You'll give up all sorts of other helpful systemd features that way, but if you're really keen on doing everything yourself anyway that shouldn't slow you down a lot. As a half-way solution, systemd service units do allow you to specify arbitrary shell commands to execute when a service is to be launched, and those should be able to let you do pretty much anything if you need to.

In actual practice, init scripts are usually 90% or more boilerplate and you pretty much have to compare them side by side to find if there are subtle differences between any two on your system. In spite of the fact that they're all largely identical they're still in separate files, though, so if you want to enable a feature like runtime monitoring of services or private /tmp directories you have to put it into every single init script by hand and carry those modifications yourself across updates of those init scripts. Having these features provided in one central place and accessible via a configuration switch is a lot more convenient and future-proof and the chances that any bugs will be found and stamped out are way higher if the code occurs in only one place instead of a few dozen.