Bugzilla

Yes, this is triggering poor behavior across multiple conferencing sites.  It affects Windows and Mac, where Firefox does not expose speaker output monitors as microphones.  Output monitors are exposed as microphones on Linux.

When the system default speaker has no microphone in the same group (including a built-in speaker on a system with no built-in microphone) and permission is granted for microphone exposure:

https://webrtc.github.io/samples/src/content/devices/input-output/, describes a headset speaker as the output device when output is in fact the system default speaker.
Neither the system default speakers nor the first exposed "Audio output destination" headset speaker can be selected in the UI because the first is assumed the system default.
When a second headset is connected, its speaker can be selected, and the first headset speaker can subsequently be selected, but there is no way to switch back to the system default.

Similarly whereby.com indicates that a USB headset speaker is the output when the output is in fact the system default speaker device.  Behavior with a second headset is similar to "input-output" above.

meet.jit.si doesn't say what is the output device while output is (initially) directed to the system default.  Output can be switched to headset speakers, but can't be switched back to the default device.

Speaker selection is ineffective in Firefox on zoom.us and meet.google.com even when all speakers are exposed, so the issues there might not be immediately related to this bug.  Output is always directed to the system default speaker.
* zoom.us has a separate "Same as System" speaker, listed last.  Speaker selection is effective in Chrome, where "Same as System" is first.
* meet.google.com indicates that a headset speaker is the output (when the output is in fact the system default speaker device).

Yes, this is triggering poor behavior across multiple conferencing sites.  It affects Windows and Mac, where Firefox does not expose speaker output monitors as microphones.  Output monitors are exposed as microphones on Linux.

When the system default speaker has no microphone in the same group (including a built-in speaker on a system with no built-in microphone) and permission is granted for microphone exposure:

https://webrtc.github.io/samples/src/content/devices/input-output/, describes a headset speaker as the output device when output is in fact the system default speaker.
Neither the system default speakers nor the first exposed "Audio output destination" headset speaker can be selected in the UI because the first is assumed the system default.
When a second headset is connected, its speaker can be selected, and the first headset speaker can subsequently be selected, but there is no way to switch back to the system default.

Similarly whereby.com indicates that a USB headset speaker is the output when the output is in fact the system default speaker device.  Switching behavior is also similar to "input-output" above.

meet.jit.si doesn't say what is the output device while output is (initially) directed to the system default.  Output can be switched to any other headset speakers, but can't be switched back to the default device.

Speaker selection is ineffective in Firefox on zoom.us and meet.google.com even when all speakers are exposed, so the issues there might not be immediately related to this bug.  Output is always directed to the system default speaker.
* zoom.us has a separate "Same as System" speaker, listed last.  Speaker selection is effective in Chrome, where "Same as System" is first.
* meet.google.com indicates that a headset speaker is the output (when the output is in fact the system default speaker device).