First, I have to plead guilty: my own product's CEC still has many "simple" flaws.
That being said, I indeed have the feeling that CEC is specifically badly implemented by most people.
I feel like the standard is rather under-specified (or there are things I don't understand), like it's said how some kind of devices are supposed to behave based on some commands, but no explanation as to how other devices are supposed to behave on those commands.
For instance, it is specified that a Player (there are various types of devices in CEC, more on that later) can send an AVR (which is different kind of CEC device, there can only be one in the whole network) volume commands. More specifically, a Player can send an AVR VOL+ and VOL- key presses to change volume. What happens if you send VOL+/VOL- to a TV? That's not specified until 2016 with CEC 2.0. So you can't control volume on most TVs if you don't have an AVR.
The number of "slots" available per device kind is constant: exactly one TV, exactly one AVR three players, 4 tuners, 3 recorders. You have a tvbox, and three game consoles (all shold be Players)? Well someone will have to lie and become a tuner or a recorder, or they won't be allowed on the bus.
Another thing that makes this messy, is that CEC needs to fit in small power budget during suspend. For instance, in Europe, the legal power budget in sleep is 0.5W. This means that your main application processor can't handle CEC in suspend. Usually, this leads to multiple "concurrent" CEC stacks, running in different CPUs, switching from always-on Cortex-M, to full-blown Cortex-A (and then you add Android TV on top of that with its own CEC stack, and you get three CEC stacks co-working together). Often the communication pipeline between those people is pretty light, and going through all those layers, you might end up losing the info of whether the wakeup instruction came from your remote (so you legit want to have the TV wake to you), or from CEC (so you want to let TV decide of the output).
I believe one gigantic factor is that CEC has started very poorly (no matter the reason), and since then, interoperability problem has been considered by most QA as "yeah well, this is life"
Back specifically to your question "I.E. "one touch play" turning on unintended devices in addition to your display and receiver.": This is very very usual. I don't know what the specs say precisely, on the matter, but here's what I witnessed on many TVs (many enough that I expect this to be the standard, but it's possible it's related to what I said earlier about dual-stack):
- Say you have HDMI1 and HDMI3 devices connected, you suspended TV on HDMI1, you wakeup from HDMI 3.
1) On wakeup, TV sends Set Stream Path to the previously selected device. If you suspended your TV on HDMI1, and you're waking up from HDMI 3, TV will start with a Set Stream Path to say "hey, the screen I'm currently displaying is HDMI 1".
2) HDMI1 device listens, and wakes up. In the process of waking up, it needs to tell the TV it is ready with ACTIVE_SOURCE command, so they do.
3) If HDMI3 is in the "clever" range, HDMI3 will send again "Please TV switch to HDMI 3" with ACTIVE_SOURCE
4) Even if HDMI3 isn't in the "clever" range, TV will later send Set Stream Path to HDMI3, because it remembered HDMI3's command to wake up to them, or because of thanks to -3-
5) Everyone's happy, TV's on HDMI 3
6) Message sent in -2- finally manages to reach the bus more than one full second later, because HDMI1 is less aggressive on CEC bus than the other.
... And there you go, TV switches back to HDMI 1.
Fixing this is possible, HDMI 1 "just" needs to cancel -2- when seeing -3- or -4-, but most CEC implementation's send_pkt doesn't include cancellation signals. So, it's possible to make better CEC implementations (though it requires mechanism that are pretty complicated for an embedded world), but I don't think it's possible to make a perfect implementation that will never miss.