It seems to me that the problem you're all having is that everyone is
right, and everyone is also wrong - and hence you're never going to
arrive at any kind of consensus, as everyone knows that they're right,
hence none can see that they're also wrong.

The problem is that you (all) appear to be seeking a general rule to
apply in a situation where no general rule can sensibly apply.

Because of that, everyone can spot the cases where whatever rule is
applied will break the things that matter to them - and they're right.
On the other hand, because they know that they're right to prefer
their position, they also know that anyone who prefers an alternative
is wrong, and hence there must be a fix for them, which seems mostly
to amount to "symlinks will work for you".

When a discussion descends to this kind of point it is almost always
a very strong hint that either the wrong question is being asked (one
which has no rational solution), or that no-one has managed to hit upon
the one really good answer yet.   In this case, I suspect it is the former,
but, of course, it isn't helped that the question is about naming, which
is one upon which everyone can (and usually does) have an uninformed opinion.

Here the problem seems to be to basically be that there is no one true
place in which all packages should store their config files.   That's
because (IMO) there are multiple radically different kinds of config files
which have quite different contents, and which need to be stored in
quite different places.

Some config files (such as the ssh identity files, but also others that
aren't (now) package related, like /etc/myname) contain info on the identity
of the host on which they're run.  By their very nature they cannot, and
must not, be shared.   Putting them any place where they could conceivably
be shared is lunacy - and "but you can use a symlink to move them somewhere
private" is not good enough, the aim is (or should be) to have things "simply
work" for the people installing packages that don't have a perfect 
understanding of what they are doing.

Then there are other config files (such as sshd_config) which contain the
kinds of information (administrator policy) which it very likely makes sense
to share everywhere there's a common policy (generally, throughout a site).
Putting those somewhere where they can't easily be shared is just as dumb
as putting the unshareable ones in a place where they can easily be.
Insisting on a symlink to make them shared is wrong, for just the same reason
as above (though not quite as wrong, as here things work the out of the
box way, they're just less convenient, and harder to make convenient).

Further, there can be config files that make sense to share, but only
among a common architecture, or common OS, or both - those you ideally
want somewhere where they will be appropriately shared (most probably in
a sharable location under a directory that contains the architecture or
OS name, or both).

Note - it was no accident that I chose ssh related config files for both
examples above (and if ssh had architecture or OS dependant config files
I would have used it again in the third case).   For any one package
there can be config files that can, and should, be placed in different
places - they don't all have to be together.   Further, with the package
file database that seems to be coming along very nicely from messages in
another thread, the one argument for keeping them all together is very
quickly vanishing completely.

That means, that you should forget the A B and C suggestions proposed as
the solution to all evils - none of them is (and hence I fully understand
all of the people whose main point was "not x" whichever of A B or C 'x'
turned out to be).

Instead, the aim should be to provide 3 (or perhaps 5) places into which
packages can place their config files - one for host dependent files, one
for reaosnably site shareable config files, and one (or three, depending
upon how it is set up) for conditionally shareable files.   Then tell
package authors (maintainers) to choose for each individual config file
which is the right place for that particular file, and cause that to happen.
People who know what they're doing will be able to override the three
locations in their mk.conf files (or on the command line, or however they
prefer), while for everyone else who just installs things exactly as they
come, everything will work in a rational, and easy to describe, setup.

This does mean a little more effort from the package maintainers, but that's
a one off, once for each package, not once each is installed, and is
definitely a trade off worth making (and no, I am not one of those who has
to do the extra work, so treat this with the respect it deserves...)

Further, for those who prefer packages to be kept totally separate from the
"base" distribution, please note the (totally reasonable and nice) effort to
make the base distribution be packages as well.   There will someday be
no distinction anyone can easily tell between what is "base" and what
isn't - not even whether the thing in question is maintained by the
NetBSD team or not (some of the add on packages right now are NetBSD
stuff anyway).

kre

ps: while all this work on config file naming is being done, it would be
truly nice if there was an easy way to tell packages (both base and add on)
when they're compiled (I appreciate that this is way too hard for binary
installations) what the basic file name of the config file should be.   Eg:
I prefer to store all config files in /etc/conf/<entity-name> where others
appear toprefer <whatever>/<entity-name>.conf  ... the leading <whatever>
is the current topic (and please don't treat this as a request that it be
/etc/conf - that's something I can manage for myself), this request is that
something be done, somehow, to allow the ".conf" part to be optional, and
variable (so people who prefer can use ".cf" or ".cfg" or whatever appears
nice to them, and so I can use nothing at all).  Bu all means keep ".conf"
as the default if that's what you like.