Found a thread on Reddit from July 2024 that describes the identical problem. I'm thinking this has been a long lasting issue.
I’m seeing the same issue with two 8BitDo Ultimate 2C controllers on my SteamDeck. Whichever controller wakes up first always takes the first profile, regardless of which physical device it is. Profiles should be tied to the Bluetooth identity, but that doesn’t seem to be happening right now.
IMO, it’s wild to imagine Valve shipping a home console device with this not working correctly, especially since a console setup makes this scenario far more common than it currently is on the Steam Deck or with niche custom hardware setups.
Confirming the underlying identity failure with two identical Xbox Elite Series 2 controllers over Bluetooth on Nobara 44 / Steam Big Picture.
Linux and SDL have enough information to distinguish them:
045e:0b22, but their UHID parents expose distinct Bluetooth addresses in HID_UNIQ.UniqueId and currently has no composite/target controller devices active.SDL_hid_enumerate(045e, 0b22) calls against both system SDL 3.4.14 and Steam's own bundled SDL3 (SDL-release-3.4.0-1163-g2d7f30078) return the two distinct Bluetooth addresses as serial numbers.Steam's controller log nevertheless reports serial_number: - 0 and Invalid or missing unit serial number, then generates synthetic IDs such as 45e-b22-3ec3d0 and a suffixed variant. During six successful reconnect cycles of one controller while the other stayed connected, Steam assigned a fresh path (sdl://15 ... sdl://20) but reused index 0 / XInput slot 0 and the same synthetic ID each time.
So the Bluetooth identity exists in kernel/BlueZ and reaches Steam's bundled SDL, but is lost between SDL enumeration and Steam's controller identity/slot logic. This appears to explain why wake order can take over names/slots.
We also observed one nondeterministic reconnect where both controllers appeared connected but only the first produced usable Steam UI input. Recovery depended on power-on order. Six subsequent raw-captured reconnects passed, with the old UHID instance fully removed before each new one and evdev input present. Related behavior and capture details: ValveSoftware/steam-for-linux#13136 and ValveSoftware/Proton#9654.
Nothing extracted yet.
While Steam OS and Steam itself allows the user to 'name' controllers and also assign them numbers though Steam Input for which will be Controller 1, 2, 3, 4 and so on.
I've been testing this for using a Steam Deck or other PC using Steam OS for a separate 'couch gaming' setup at a LAN party but it doesn't seem to be viable.
I've been testing with Steam OS 3.7.15 and Xbox Series controllers over BlueTooth
Let's say the system is left unattended, and all controllers go to to sleep. They were all given names in Steam OS to identify the controller's color 'Player Pink', 'Player Purple', 'Player Blue' and 'Player Red'. They were all assigned controller slots 1, 2, 3 and 4 respectively. Which ever controller is woken first, regardless of which controller it ism will now be named 'Controller Pink' and given Controller Slot 1, even if it was not the pink controller. The second controller to be woken will take the name 'Player Purple' and Slot 2 and so forth.
This not only undermines the very premise of being able to give controllers names when the names will be assigned to whatever they want but also makes it futile to clearly mark controllers as '1, 2, 3 & 4' for couch play when Steam OS will happily rearrange that numbering depending on the order on which the controllers are woken up. It will do nothing but cause confusion to players as they must fiddle with controllers to determine which one controls each player if they were allowed shutdown and not activated in precise order.
I would assume the unique MAC address to any BT device should make unique identification of any controller viable but Steam OS is not doing so.
I've not tested this with any other controllers as Microsoft 'Series' controllers are all that I have multiples of. Anything else I have are 'One Ofs'