A few quick replies:

Omitting -pipe did nothing, just slowed things down visibly.

This was a clean source tree and clean install, as I already 
mentioned... the source tree was fetched to a directory that didn't even 
exist yet, and the install had not had any messy updates... and was a 
2.0 RC4 snapshot (all have worked in the same way, but this was the last 
of the i386s on the releng.netbsd.org server before it went down). So as 
far as I can tell, everything was as Right as it could have been.

To summarise, the only way I could get the build moving was to copy the 
generated includes from where they were to where they would be included 
from. I believe this to be because, in my particular case, nbmakedep 
does not imply -I. even for ""-included headers (as opposed to <>). 
Weird, eh?

Trying David's line now, (had to move update to before -I - cvs flag 
parsing 'feature') seems to be cleansing quite well, but I don't yet 
know how this will affect the build... since the tree was 'clean' when I 
fetched it, and there was nothing in /usr/obj either.

I'm still stumped on why it happens though. Yes, I have used build.sh 
for 80% of my build attempts, and no matter how I used it, by the book 
or by the help, nothing was any different.

Let's say that, on a completely fresh install with all usual sets, this 
would be my strategy (assume basic configuration and all that is done):

(All as root - could THIS be a problem?)
cd /usr
setenv CVSROOT anoncvs@anoncvs.netbsd.org:/cvsroot
setenv CVS_RSH ssh
cvs -z5 checkout -rnetbsd-2-0 -P src
cd src
./build.sh tools distribution install=/
(Well, usually I build a kernel *first*, but this doesn't have any real 
impact)

As far as I can tell, the cvs stage is not the problem, because the same 
problems occur with sources unpacked from tarballs, or even CVSup'd from 
either of the two mirrors.

Anything horribly wrong with that procedure, which would warrant 
cluebatting me?