User=0day considered harmful in systemd

Hmm so the logic of the commit message makes a subclass of configuration options that will always fail if an error occurs if parsed.
That seems reasonable. As a short hand I'll refer to this subclass as "sensitive directives"

Question the first:
Would it make sense to give local admins the ability to extend the set of sensitive directives with more directives of their choosing?
The commit comment refers to other supplemental directives that can't be guaranteed to parse correctly across all system configurations in the general case from a unit writer perspective.

I would think however that a local admin may want to use their discretion and local system knowledge to treat specific supplemental directives as sensitive and have the units fail to start if the directives fail to parse to avoid unexpected behavior.

I would also naively think that distributors who are supplying unit files to end users might find it useful to use some automation and audit for parse errors on a much larger set of directives. Since these distributors generally set the compile options, they are in the best position to test to make sure supplemental directives outside the default set of sensitive directives fire correctly.

Question the second:
What's the best practice for local admins/unit writers/distribution integrator to be notified of directive parse errors in the unit files on system? Is there a way to automatically audit the disabled/inactive units for these sorts of errors?

Question the third:
Should this be taken further and create a subclass of directives for local admins to populate which much be present and parse correctly in all units?