Labels outside the switch also work.[2]
[1]: https://my737ng.com/wp-content/uploads/2014/08/cp_mcp_header...
[2]: https://i.pinimg.com/originals/2c/37/0a/2c370a3f4018cfa9c3ef...
On the Apple side, things look a lot better. They were able to keep most apps using the native UI.
MS had it in the bag too! Everyone wanted that 'sticker'. If you didnt have it almost no one would put your software on the shelf. To get that sticker you had to pass their usability tests that followed their style guide. Then they did like you said and switched it at least 2 times ever OS release.
Plus the web got in there and there were almost zero standards there. So we ended up with dozenes of framerworks that 'do it for you' and those have at least 3-5 generations of goop.
Because computer people aren't optimizing for functionality, intuitiveness, or really any sort of UX.
They're optimizing for some idea of "beauty" and whatever is trendy.
What I ended up settling on to replace them was a button for each option, where the respective button would light up to display the current state. For example, what would be an on/off toggle became two buttons labeled on and off. Initially both buttons were grey, and when the UI received SOH from the hardware indicating that the state was on, the on button became green, or for off, the off button became red. If communication was lost for some time all the colors became desaturated, to indicate the state was stale. When a button was pressed, the old state continued to be displayed, but desaturated (for just that button set), until a new state was received back. The user could always command the system on or off at any time (by clicking the respective button) regardless of what state the UI though it was in, unlike a toggle which only lets to you change to the "other" state. Likewise, radio buttons were replaced with a series of buttons labeled with their state, and the one the UI thought was current was colored (using blue for most "neutral" states and green/yellow/red if the state had a good/warn/bad meaning to the operator that they wanted to highlight).
Despite the atypical design, I found that operators generally understood the interface without training - buttons looked like buttons so they must be clickable. The spacing of buttons made it clear they were a set, and since grey was the default color of everything in 90s UI, the button that was colored differently stood out and must be the current state. I don't know if that would be the case today, where UI element can be any color chosen for aesthetics or funneling and only sometimes communicate information.
I did experimented with displaying both the commanded state and received state in various ways (akin to NASA's buttons), but all ended up being more confusing.
> I did experimented with displaying both the commanded state and received state in various ways
Did you try keeping the commanded button in the pressed state until the next state update? I feel like that should be fairly intuitive to most people, and it'd still allow you to give a different command while the state hasn't updated yet.