>bsd.README says:
> It's fairly difficult to make the BSD .mk files work when you're building
> multiple programs in a single directory.  It's a lot easier to split up the

You can use bsd.*.mk with .for loops to achieve this.
Nested evaluation makes it simpler too.

SRCS_foo = fu.c bar.c
SRCS_goo = zoo.c
etc
and then
SRCS=${SRCS_${PROG}}

etc.  Building libs and progs in the same directory is also messy but
possible.  Best bet is to probably put your wrapper magic in a rules.mk
(like ODE used), and have it .include {lib,prog}.mk etc.

Anyway, I've done it, but it gets messy quickly and its generally easier
to setup the tree to make life easier.  Even if you have some 3rd party 
s/w in contrib/thing you can setup suitable Makefiles elsewhere in your
tree to build libs and progs separately, and one prog per dir is no biggie 
when the Makefile can typically be as simple as:

PROG=${.CURDIR:T}

.include <bsd.prog.mk>

> programs than to deal with the problem.  Most of the agony comes from
> making the "obj" directory stuff work right, not because we switched to a
> new version of make.  So, don't get mad at us, figure out a better way to

This is orthogonal.

> handle multiple architectures so we can quit using the symbolic link stuff.

That's easy enough, just set MAKEOBJDIR to something that involves 
${MACHINE_ARCH} (my build at work uses this to build multiple arches in one
tree).  I actually use separate objdir trees with only the top level dir
named say obj-${MACHINE_ARCH} and the rest being directly parallel to the 
src tree - allows great simplification of makefiles when the Makefile for
foo can _know_ that libgoo will be at ${OBJTOP}/lib/goo/libgoo.a etc.

With the new .OBJDIR target introduced a little while ago, you can
probably achieve the same goal without needing to frob the environment.
However to get reliable results you really need to control the build 
environment (PATH, MAKESYSPATH, and making sure that LD_LIBRARY_PATH, etc 
are not set) for which some kind of wrapper script is needed 
(eg. the build.sh netbsd now uses).

>My goal is to find a way to provide equivalent functionality to automake
>using a pmake derivative (*BSD make, basically) and a set of .mk files.

Don't know - never used automake enough to comment.
But I've used things like 

.include Makefile.${HOST_TARGET}.inc

to automatically pickup magic specific to a build host.
So I've had little trouble NFS exporting a src tree (read-only) 
and building it on NetBSD, SunOS, HP-UX, AIX, IRIX, Linux, ... 

Actually I used to build bmake (the autoconf'd version of netbsd's make)
such that on platforms other than NetBSD it set MACHINE to an equivalent
of HOST_TARGET, but I don't do that anymore - just let sys.mk or your
environment provide a suitable HOST_TARGET setting.

--sjg