Well, I've had some time to write up my thoughts on this. Here they
are:

0. I was surprised to see this thread die out so quickly.  I hope that
doesn't indicate a lack of interest. I've been wanting something like
this for _years_. Further, this particular proposal opens up a way to do
named partitions reasonably (see below), which I see as being just as
valuable as cross-platform partition map support, perhaps even more so.

1. Since this is going to create a fair amount of /dev clutter, I
suggest putting all the nodes under /dev/dsk. I know this will offend
some people's sensibilities, being SVR4-like, but I don't see that a
non-flat /dev is nconsistent with the NetBSD way of doing things.
We put all the files for different ports under /sys/arch, after
all -- why not group disks together too? I'm assuming in examples below
that this is acceptable, but if it won't fly, just elide that component
of the example filenames. Still, I see some advantages to having it
under a separate tree: easier to have that directory managed by a vfs in
the future, if that's desirable. Easier to clear out the generated
names a boottime, if that's desirable. And so on.

2.  For partition map types that support named partitions (RDB, for
one...  do any other NetBSD-supported machines have this concept?), the
disk name should *not* be a component of the wedgeconfig-generated link. 
IE, if sd0 is partitioned with RDB's, and has a partition named
"NetBSD-home", the generated link or node should be
/dev/dsk/rdb/NetBSD-home, not /dev/dsk/sd0/rdb/NetBSD-home.  Why?
Because then if my fstab says something like:

/dev/dsk/rdb/NetBSD-home	/home	ffs rw		0 2

I can take what is now sd0, change it's SCSI ID and move it to a
different controller, and it'll still mount fine without editing fstab. 
No more worries about nailing down sd unit numbers, etc. Put it where
you like, and NetBSD will find it. It could even be on removable media,
and if I have more than one drive, it doesn't matter into which I
load that disk. In the specific case of the Amiga, it also would make it
easy to access adosfs filesystems and be sure of getting the right one:

/dev/dsk/rdb/DH0	/ami/dh0 adosfs ro		0 0

This is of particular advantage to Unix newbies coming from AmigaOS:

"What do you mean my DH0 is now called sd0j? What do you mean it might
change to a different name if I change partitions around? I gave it a
name, how come NetBSD just can't find it that way?"

3.  We should invent a new, architecture-neutral, scalable, extensible,
partition map format that supports named partitions, so that this
capability can easily be used everywhere.  I'd suggest something close
in spirit to RDB (linked blocks, flexible placement of root block), but
with a less platform-specific bent and with some fields expanded to 64
bits (RDB is limited to a little less than 2TB if my calculations are
right.  A time when this is too small is not that far away). If this is
thought a good idea, I'll elaborate further on it. 

4. For those partion map types where names aren't defined, but where we
can add them in a backward compatible manner, we should do so.

5. The choice of which format to use is still left up to the user. If you
have a box that's got Linux and NetBSD on it, and you want to share some
partitions, keep them under MBR, so Linux can easily find them.  If you
have a NetBSD-only box with lots of disks and a tendancy for things to
move around a lot, use the new format.  Likewise if you have a large
RAID array or somesuch, that is larger than MBR can handle (how large a
disk can an MBR-type scheme span, anyway?), use the new format.

6.  Perhaps (even "Probably") the generated name for name-capable
partition map types shouldn't even include a component specifying what
type of partition map it was found in.  Maybe just
"/dev/dsk/NetBSD-home".  Or "/dev/disk/named/NetBSD-home", if you want
named partitions grouped together.