>thought it could without using it together with MAKEOBJDIRPREFIX, which
>is not exactly what I had intended.  (This is because I, as I'm sure

Or MAKEOBJDIR which is ultimately more flexible - see below.

>Multiple "simultaneous" builds (cross and/or build-ID) on the same host
>from the same source directory could be done without including $MACHINE
>and/or $BUILDID in the "obj" symlink name, provided that 'make' were
>modified to allow a prefix to be specified that would be stripped from
>the full value of getcwd() before it is appended to MAKEOBJDIRPREFIX.

You don't need anything new in make to do that.  I've described 
how to do this a number of times using MAKEOBJDIR - which is what 
my build at work uses.  make(1) will do variable expansion on
MAKEOBJDIR* before using them - this has been true for a couple of 
years.  So you can use:

MAKEOBJDIR="\${.CURDIR:S,\${SRCTOP},\${OBJTOP},}"

which will automagically do what you suggest.
You can get just as creative with the setting of OBJTOP, 
eg having it set to /some/where/obj.\${MACHINE} means that a multi-arch 
build "just works".

>BSDSRCDIR used during "make obj".  (This has actually been something
>I've thought of for some time now, but here finally is a concrete
>example of where it such a feature proves not just useful but
>necessary!)

Yes, being able to rely on the object tree being a neat parallel of the 
src tree, allows many things to be simplified - resulting in faster builds.
But to achieve any such benefits you really need to be able to
nail everyone down to doing things one way. Not an easy task. 

>If one always uses build.sh for cross-builds then it would hide any
>complexity and always set MAKEOBJDIRPREFIX (and MAKESRCDIRPREFIX)
>appropriately for a given build of any number of architectures (even all
>run actualy simultaneously).

Yep, exactly.  I actually stash all the magic env variables in
$SB/.sandbox-env, and the make wrapper (mk) searches for that file
to determine what SB should be set to, sources it and returns to
its starting dir to exec make.  This makes it _trivial_ to have a
dozen different trees from different branches/projects etc using 
different toolchains etc, to all be worked on simultaneously.
Switching from one setup to another is no more complex that "cd".
Even better, "M-x compile" using 'mk' "just works" for all those 
different trees.

The mechanism itself is very generic - I use it at work, on my netbsd trees
and lots of other projects.

>  first set in /etc/mk.conf (and of course put your source in /usr/src):

For any kind of version controlled environment, /etc/mk.conf is a bad
idea. If you want to make a CD of the build tree for realease N of your
product you really want to be able to mount that CD later on and be 
able to re-build accurately.  Any reliance on something like 
/etc/mk.conf is a problem.  

>(Pmake's use of $MACHINE (or utsname.machine) in forming objdir has
>never made any sense to me except perhaps for the very rare case where

Try building a release that needs to build products for multiple 
architectures out of the same tree make's support of $MACHINE and 
$MACHINE_ARCH make this quite simple - with nothing more involved
than "mk release" or whatever your production target is called.

>one is forced to put objects in the source hierarchy and where the
>source tree is shared with NFS or whatever on multiple architectures,
>but even then such constraints seem extremely silly and contrived -- why
>a single "obj" symlink pointing to a second NFS mount of space unique
>for each host, or through an intermediate private per-host symlink that
>points to another unique-per-host location on the same mount as the
>sources, can't be always used is beyond me.  Even on a totally diskless

Like I said, try to built bin/cat for multiple architectures as part
of the same "release" build.  Having MAKEOBJDIRPREFIX=/var/obj.\${MACHINE}
or the fancier MAKEOBJDIR usage above, makes it trivial - even with a
read-only source tree.

--sjg