Let me clarify my position.

It's a good thing to make this stuff configurable and extensible. I like
that. Good show!

However, I shouldn't *have* to configure it. Absent a configuration file,
the new code should implement the old default behavior. This approach gives
those who wish new functionality the thing they want, without screwing
everyone else. Principle of Least Astonishment applies here.

I have not yet seen a compelling argument for requiring a new configuration
file to get the old behavior.

As a *completely* separate matter, if we're thinking about changing
defaults, we need to think that through carefully. There must be an
excellent argument for why the change in *defaults* is necessary, doubly so
when the behavior is now configurable.

Personally, I think the existing defaults work just fine, and they are what
the majority of NetBSD users are using. Why change? What's the Big Win?

No matter what we decide, it is important to prominently document it, and
link it all to heck so that it's easily found. There is nothing worse than
a new configuration file which fundamentally changes the behavior of a lot
of programs, and you haven't the faintest idea where to even start looking
for it.

The quotation which suggested that I was in favor of changing default
behavior was misattributed.

	Erik <fair@clock.org>