From Jan:

That's a more reasonable size than your first example. Although this ...

Allowing the sysadmin to completely override the service.
Unfortunately this also forces the sysadmin to override the service for
every so little change,

... then begs the question: what's the advantage of having the
${S6CONFIGDIR}/system/config/seatd entry point at all? How much effort
does this save the admin over creating their own my_seatd service and
disabling the one you provide?
(Honest question, I don't fully grok s6.)

It does not have anything to do with s6 itself,
it just allows original service scripts to sit at /usr/lib/s6-rc/{user,system}/src/service
and be recklessly updated by the package manager.

Installing them initially to /etc/s6-rc/{user,system}/src/service and editing them in place
will not allow that. This is in part mitigated by:

I am not sure if I understand correctly, the files under
/usr/share/s6-rc/{user,system}
are to be there only as a reference, not to be edited.
Are you trying to say that the non-edited files should be symlinked rather
than copied?

I was indeed trying to say that.
But on second thought: you should do whatever Gentoo usually does with
such configuration files. Consistency trumps any minor advantages any
particular approach might have.

But this introduces needless complexity just to save one line in every script.

The best would probably be for s6-rc-compile to allow for multiple definitions of a service,
letting later definitions override earlier ones, e.g.

s6-rc-compile ${OUTPUT_DB} ${SOURCE_1} ${SOURCE_2}

where seatd-srv in ${SOURCE_2} overrides seatd-srv in ${SOURCE_1}.

Would this be realizable Laurent?

Regards,

Paul