Policy defines configuration files as:

    A file that affects the operation of a program, or provides site- or
    host-specific information, or otherwise customizes the behavior of a
    program. Typically, configuration files are intended to be modified by
    the system administrator (if needed or desired) to conform to local
    policy or to provide more useful site-specific behavior.

The word "typically" here makes a reading that all files containing
configuration information, whether or not they are intended for editing,
might need to be in /etc. This is pretty clearly not the intended meaning
given historic practice in Debian (see, for example, *.desktop files, the
files in /usr/share/zsh/vendor-completions, /usr/lib/news/innshellvars,
or /usr/share/autoconf/autom4te.cfg, all of which hold configuration
information but are not intended to be edited).

I believe we should reword this definition to make it explicit that Policy
is not saying that every source of configuration information must be in
/etc, but rather that any file a system administrator may reasonably be
intended to edit as part of configuring the software for use on a specific
system is a configuration file (whether or not it is a conffile), and
therefore should be in /etc.

We may want to explicitly say that this is consistent with a model where
defaults are loaded from a file in /usr and then overrides are loaded from
a file in /etc, since this configuration practice is becoming more common
and seems obviously superior to a model where defaults are hard-coded in a
binary.

Hello,

Indeed, this isn't great text both for all the not-intended-to-be-edited
stuff we have shipped there, plus the /usr-and-overrides thing more
recently.  Thanks for the write-up.

... which by the way is not particularly recent, the layered override was
implemented for TeX in kpathsea in 1993.
I always considered to be the best scheme for handling upgrade, I am glad
to see it is more widely used.

Cheers,