One of the old Unix-ish philosophies for tools is “mechanism, not policy.”I first heard this phrasing as a mantra for why X11 was the way it was sometime in the early 1990s, but I’m sure it goes back further.
That is, low-level tools should provide a way to do things, but shouldn’t enforce any specific pattern of use.
There’s a really common failure mode here, though, where people design mechanisms that are so policy-free that they’re almost unusable, or where every individual user ends up interpreting the mechanisms provided completely differently, breaking compatibility and confusing users. Google was full of this sort of thing internally before 2015 or so, to the point where our most common configuration tools were mutually incompatible between different teams, even though they used the same language to do the same basic things.Specifically, borgcfg (effectively the thing that kubectl was derived from) had its own language for defining the various parts of services, but there was so little policy involved that the entire structure of configurations was grossly incompatible (and mutually incomprehensible!) between teams, making it impossible to build any sort of shared libraries to simplify things like “this process should use X GB of disk plus the sum of all of the disk needed for all of packages that it uses”.
Unfortunately, HDMI CEC is clearly another example of this same basic problem, and the specific way that Apple has implemented it with MacOS means that you can’t plug two Macs into the same Samsung TV without breaking things.
CEC (“Consumer Electronics Control”) is the HDMI feature that lets devices talk to TVs and tell them things like “please turn on”, or “switch to my input”, or “turn up the volume”. When it works right, it’s magic. When it works wrong, unfortunately, it’s also magic. Of the cursed, un-debuggable kind.
I upgraded from a M2 Macbook Pro to a M4 Macbook Pro over the summer (new job, new computer), and discovered that M4 Macs now support HDMI CEC. Since I use an 8k TV as a monitor, this made life much more pleasant – waking up the computer turned on the TV and switched it to the correct input automatically. It was like magic. The good kind.
Then in November I added a Mac Studio to the mix, and the bad magic reared its head. I’d wake up the laptop and the TV would switch inputs, but then it’d blank out after a few seconds. Then it would come back. Then go away. Over and over again. Both Macs worked the same way. I tried swapping HDMI cables, I moved inputs around, all of the usual things, and nothing worked consistently. It’d work for a while, then break again.
Eventually, I realized that there was one thing that I could do that would fix the problem: it always worked perfectly when one Mac was plugged into the monitor, and almost always failed when two Macs were plugged in. As soon as I realized this, the problem became pretty clear – the Macs were reacting to each other’s HDMI CEC messages and they kept turning the monitor on and off.
The simple fix was simple: when I switched computers, I needed to power off the TV and then power it back on. That broke the cycle for long enough that it’d stay working. It was terrible and annoying, but it was simple and it worked.
The better fix? After extensive research, I’ve concluded that it doesn’t exist. Which is where “mechanism not policy” comes in.

scottstuff.net

M4 Macs with HDMI CEC support create conflicts when two are connected to the same Samsung TV, causing the display to repeatedly turn on and off. The issue stems from Macs reacting to each other's CEC messages with no way to configure the behavior. The HDMI CEC standard lacks proper usage policies, leading vendors to implement incompatible interpretations. The only workaround is power-cycling the TV when switching between Macs or disabling CEC entirely, as Apple provides no settings to control CEC behavior.

The Two-Mac HDMI CEC Problem