>>       parent* at wherever
>>       child0 at parent0
>>       child* at parent1

> The last one isn't really acceptable, as instances of the parent
> device may suddenly be probed in another order, thus changing the
> identity of child0 and its siblings.

So?  "You asked for it, you got it."  It makes sense to me to say "I
don't care which of these is parent0, but I want child0 to be the one
attached to parent0, whichever one that is".  It's hard to see a use
for this in most cases, because most things that can be attached to
don't have interfaces of their own, but if both parent and child can be
open()ed or otherwise manipulated in their own right, getting things
paired up correctly can be important.

The only case I can think of offhand where this could actually be
useful would be some kind of hardware resource that is accessible only
to software - no external hardware interface.  Take a crypto
accelerator, for example, which can provide AES, DES, and/or Blowfish
support (yes, I know this is not how crypto accelerators are actually
done):

	crypto* at wherever
	aes0 at crypto0
	des0 at crypto0
	blowfish0 at crypto0
	aes* at crypto?
	des* at crypto?
	blowfish* at crypto?

This guarantees that if aes0 exists, the crypto instance it attaches to
is crypto0.  (It also guarantees more, eg, that if blowfish0 and aes0
both exist, they are attached to the same crypto instance.)

I definitely am not sure enough that there is no use for such a thing
to forbid it by fiat.  "Unix does not stop you from doing stupid things
because that would also stop you from doing clever things".  Warn about
it, fine (especially if there's a config file directive to suppress the
warning).  But error out on it?  I don't like that.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B