So, from my perspective, your strategy of trying to get your way with
NetBSD seems to be:

	* Every time people do things the other way, bring up the
	  argument on a mailing list in a voluminous mail message.
	* Every time someone reponds, write a one-page response to
	  every paragraph they write, repeating everything you've
	  already said, perhaps slightly modified to reflect some
	  evolution in your thought process.
	* Never notice the fact that everyone who commits code seems
	  to disagree with you every time you bring up the issue.

I don't think this is a very productive strategy.  It doesn't tend to
get you your way, and it adds tremendously to the volume on the
mailing lists.  Perhaps you could place more value on brevity.

Greg Woods wrote:
> CVS vendor branches are "magic", relying on an otherwise pretty
> useless feature of RCS, the effects of which are not dealt with
> unless CVS is doing a few explict vendor-branch related tasks
> (i.e. primarily only "cvs import" itself).  The plain "ordinary"
> branches in CVS are also magic (using reserved revision numbers to
> mark the fact that they are "cvs" branches).  The two cannot play
> together when any degree of normal CVS functionality is expected.
> Indeed many operations on vendor branched modules have to be dealt
> with with much more care than with ordinary modules.

This is argument by assertion, and it asks those who disagree to prove
a negative.  It would be better to go back, do your homework, and get
specifics before arguing, rather than asking us to trust your
experience.

I use CVS all the time with vendor branches and local branches, to
manage a 380MB source tree.  It works fine.  The one wart I've noticed
is that "cvs update -j 1.2" will grab the patch against 1.1 when you
wanted the patch against 1.1.1.n, where n was the most recent vendor
revision before 1.2 was committed.  So I tend to specify both
revisions (by symbolic name, hopefully) when doing a merge.