The latter portion of this message includes what I hope are useful statements.
If you're not entertained by intemperate messages, skip down a few paragraphs.

I'll sand off the attribution so the lampooned party can pretend he didn't
really write something like this:
> >> True.  However, not all users are created equal, and I am not at all
> >> sure I think we want the point-and-drool crowd.
> > It's also effective at keeping out busy people of clue, and we
> > definitely don't want to do that.
> I'm not sure what to suggest here; we (or at least I :-) really want
> something that minimizes effort for the latter while maximizing effort
> for the former.

This is simply braindamaged.  What else should NetBSD make pointlessly
difficult to keep out those UNWORTHY to run it?  Remove the C compiler?
"Code in assembler, you WIMP, or GET OUT!"  The file system?  "Anyone with
A CLUE can remember which disk blocks they stored their data in!"  The shell?
"Just load the inode number in the front panel switches if you want to run
a program, REAL COMPUTER USERS don't need this command line crap!"

Computers are supposed to be tools for getting useful work done.  I simply
cannot see the act of compiling a large software package as useful work under
any circumstanced (OK, outside of testing a C compiler).  At best it is a
precursor to using that software package to get useful work done; when it
is a *necessary* precursor, it is almost invariably because the package is
sloppily designed for configurability.  When it is an unnecessary precursor,
compiling it yourself is almost always a pointless waste of time.

[Here begins the more temperate material.]

As far as directories go ("/usr/local" versus "/usr/contrib" versus
"/var/Bertrand_Russell/FroMThENeT/"), there is simply no way to achieve
universal agreement, so I would argue to just pick one of the two EXISTING
PRACTICES and be done with it; symbolic links make it relatively easy to
paper over some of the differences, anyway.  (Personally, I'd favor the
BSDI "/usr/contrib", since "local" ought to mean "local", but if we're
going to leverage the FreeBSD work, going with their choice will probably
make things easier.)  If you simply must have bizarre pathnames, get the
source compile it yourself, and get out of the way of people with better
things to do with their time.  (And please can the screeds about evil
software hoarders who will take this as license to keep their sources
secret; if you want a POLITICALLY CORRECT operating system, you know
where to get it.)

What would be really useful, though, would be an easy mechanism for
applications to use to customize pathnames and even major functional
choices.  MH has this to some degree; INN sort of provides it for INN
shell scripts, but not for the compiled programs.  Sure, it costs some
startup time to read a file and store strings, but not a whole lot (unless
you're using a MicroVAX or some other steam-driven computer), and damn it,
*I* paid for the computer, not the other way around, so it can do the work!
Systems that have had "natural-language catalog" type features added work
reasonably well.  (Nah, those non-English speakers aren't WORTHY to use
our software, why waste precious CPU cycles catering to them?)  The basic
idea here, though, is to devise a standard mechanism that application
developers can be convinced to use.

The more precompiled binaries I can get my hands on, the more spare time I
have for the poorly-thought-out programs that simply have to be site-compiled,
and (of course) the rare program where site-specific compilation really serves
a purpose.  And I am certainly not a "point and drool" user.