Wow, okay, you need to pull back for a moment.
Yes, we use a hierarchy to represent devices connected to the system.
This is combined with the fact that the things you put in that tree have a lot of information attached to them so that they know where they need to go.
In the end, each device template (any number of instances of which may wind up in the device tree for an installation) usually has plug and play information associated with it, so that when Device Detected events come in from various parts of the system (such as the HAL device for USB or PCI devices), or the DHCPd-Plugin (for Network devices), the system will know what device templates to possibly associate with the new device, so much of this is mitigated.
But for other devices, such as a GC-100, the relationship is usually
Master Interface device (i.e. GC-100)
Infra Red Porr
Infra Red Port
Infra Red Port
the GC-100 DCE device driver itself implements a ReceivedCommandForChild() method, which listens for things destined for its children (the different child ports above), and does the right thing (essentially a switch() )
Similarly, Z-Wave is implemented in the same way,
and security DCE devices like the VistaICM2 are implemented in the same way.
With that said, There is plenty of architectural help to help make this process automatic, provided the drivers or the hardware can provide the needed events or mechanisms to notify the system when devices enter or leave.