A package for an MTA (for example) will have to know how to start itself up. You're left with the following options: 1. Rework the MTA to startup with your own method 2. Have the package maintainer somehow allow both such as... 3. Post to the AUR (or whatever) another version of the same package that uses the alternate startup system.
That's why a declarative service config files help. An alternative init system could just read the "systemd" ini files and do whatever it thinks it can do better.
I'm confused as to how this solves the problem. Sounds like you've just introduced parsing into the mix ---- another unnecessary complication.
I don't understand why you think parsing is a hard thing. INI files have been around for millennia (in internet years) and both parsers and writers for them are well established in many languages. Also, bash scripts are also parsed, for better or worse. The benefit of declarative config files is that you can extract information from them by *just* parsing and not by parsing AND running them as is the case for random init scripts. Also, even making a small error in a Turing complete bash script is much more dangerous than in a declarative file, in which you'd just ignore that line. -- дамјан