> On the other hand, it should be possible for a user who cares to nail
> down the relevant details as best they can, so that if they happen to
> add a new device at a 'bad' place, or if one of their devices powers
> on non-responsive, something "close to right" continues to happen.
> 
> USB gives at least location as a mechanism for doing that, although
> it's apparently not a particularly great mechanism.
Point taken.  I'll try and get physical location as a locator
for USB.  A physical location will then be a sequence of 1-5
(there is a limit of hub depth to 5) port numbers that tells
you how to navigate from the root to the device.

This brings up the point of locators with multiple values again.
I posted a suggestion on how to do it long ago, but got very little
feedback.  And yes, string valued locators would also be handy.

> You cannot use the existence of a problem with another chunk of code
> to rationalize the problem in your code.  Yes, there's a problem with
> other code.  It's a bug there, that will cause people who have a
> serious need for the functionality there.  If you can avoid
> propagating the problem, you should.
I wasn't trying to rationalize the problem in my code.  I was trying
to find similar problems and look at how they were solved (will be
solved).  I guess PnP wasn't the place to look.  :-)

Another problem, that Terry Moore mentioned, is how to handle
the gazillion of device names that the current scheme would use
in /dev.  Should we invent a special file system (mounted at
e.g. /dev/usb/) in which devices appear and disappear as physical
devices come and go?

        -- Lennart