You apparently have some very bad hub controller IC inside your "a powered USB hub", or the board is wrongly designed and does not handle the VBUS properly. And your concept of USB devices being "awake" and "not receiving shutdown command" is a little off.
By USB specifications, every USB device (which includes USB hubs) must reset USB interface into default (unconnected/un-enumerated state) when VBUS on upstream port disappears. For this purpose all normal hubs (and devices) have a special logic input (usually) called something like "VBUS_SENSE". The input is usually connected to VBUS via a level translator (or directly, if the translation is done internally). The function of this input is (a) not to pull-up D+ when no VBUS is NOT present, and (b) reset USB interface if no VBUS is there.
If VBUS gets disconnected and connected back, USB hubs are required to set all its downstream ports into "disabled" un-powered state. Same thing must happen when the hub's upstream port receives "USB_RESET" state (both D+/D- lines go LOW for 10-50 ms).
Now, it is true that if you have a cheap self-powered (powered from external AC-DC adapter) hub that uses "ganged" power and no high-side switches, all connected downstream devices will continue to receive VBUS. After you disconnect the upstream port of your hub, the USB traffic will stop, and all devices will go into low-power SUSPEND state. They are not "awake", they will be "suspended". The devices also don't need to receive any "shutdown" command, the SUSPEND happens automatically after 3 ms of bus inactivity. In this state the devices retain their previous enumeration (assigned USB addresses). So when (if somehow) the traffic resumes, they will respond only to old addresses.
As said above, a normal USB hub will disable transmission logic on all downstream ports if VBUS is gone. So when the VBUS comes back (after re-connect to a different host for example), the traffic downstream won't resume because all ports are disabled. After the hub receives USB_RESET from root port, the hub will be enumerated anew. Then the host software will check all downstream ports for status using newly assigned hub address. If the port status shows as "connected", the port will receive "PORT_RESET" command, which in turn will generate USB_RESET to corresponding connected device and turn the port into "enabled" state starting idle traffic. The connected device will reset its USB serial interface to "default" (addr=0 endpont=0) state. The host will proceed with standard enumeration of the device and assign a valid (non-zero) address, next available. All other devices won't receive any traffic since all other ports are still disabled.
Then the host will move to another port that shows connection, and process of enumeration repeats. Even if all traffic is broadcasted over enabled ports, already enumerated devices will ignore the new enumeration traffic since they are configured for individual non-zero USB addresses. So all connected devices will eventually show up in USB device tree.
So, if you reconnect the hub cable from one PC to another laptop, the hub ports must be disabled, and the process described above must start anew. If not, then your hub is broken. Most likely the board design does not implement VBUS_SENSE function and uses external power to keep the sense active. Even then the USB_reset on upstream port will follow after new connection, and the hub must reset USB interface and disable its ports anyway. If it does not do this, it is really bad. In fact, I have not met a hub IC where the port disable function is broken. These include TI hubs, SMSC/Microchip, Terminix, Genesis Logic, VIA labs, Alcor. You must have something unique and very bootleg.
