So I setup a test for this and there indeed is a problem on a Pi 4. I setup a second simplex audio interface on Pi 4B v1.2 (the first node is a duplex node). There is definitely a condition whereby the output audio follows the "most recently active" node. Here's the setup:
Node 40608 - devstr=1-1.4:1.0 with duplex=2
Node 460182 - devstr=1-1.3:1.0 with duplex=1
Audio will only be sent out the device on the most-recently-triggered node. If I do an rpt localplay on 40608, it will start up just fine. But as soon as I trigger a localplay on 460182, then new audio stream will play on 460182 and the audio stops on 40608. However 40608 is still keydown for the remaining time of the file being played (I've use the exact same audio test file for years so I know exactly how long it is in my head). You can then immediately reverse it, localplay on 460182 and then on 40608 and the audio follows the most-recently-keyed. This is also observable with the CW ID. Trigger them to ID at the same time, and the second one "keeps" the audio.
This is definitely an issue with the USB subsystem on the Pi 4. Once per Asterisk restart, the following kernel message is logged the first time the second audio device keys:
[1110716.616818] xhci_hcd 0000:01:00.0: ERROR Transfer event for disabled endpoint slot 2 ep 1
[1110716.616843] xhci_hcd 0000:01:00.0: @000000040e808d40 00000000 00000000 0e000000 02028001
This is basically a "my USB interface hiccuped and I couldn't fix it". Claude will tell you all sorts of facts about it. MOST notably, this is not an undervolt problem on the power rails which is what I expected to find. Doing more research (which again is way faster with an AI query), this is a VL805 chip issue that's a race condition inside the chip that cannot be worked around in software.
Unfortunately, I don't have a USB A hub handy to test what putting it on an external hub does.
I'll add this to the "Known Issues" section of the manual.