You can't blame the lack of "enforcement" to be the cause of the ills created by bad standards. I'm fairly certain that 2 official certified USB-3 cables can brick devices even though the physical form factor is the same.

Relying on cables internals for function is just as stupid as can be.

I think USB-C would have been so much better if the CC system were saner - for example we could have had a shift uart like register based api:

- Host queries some property and each cable along the way appends their value to that message and passives it along.

- The endpoints either loopback if they're the new standard or pull down the pins if they're USB-2 only.

- It follows that if no message makes it back then we're limited to USB 2.0 and if a message does make it back, we can query/configure all elements along the path of connections. Right now this is impossible which makes it impossible to detect if there is a non 50v tolerant hubs between two hubs.

- The programming/hw implementation for PD and alternate mode would also be non-insane in this model. Currently PD requires stupidly complex state machines, op amps, resistor banks or some autonomous IC to pull off and there are so many screwups because it's such an obtuse standard.

- Supporting alternate modes, and providing more diagnostic information would be much easier.

There should have only been 2 passive cable types - 2.0+PD and USB 3 gen 1 - everything else should require a smart tag on the chip.

This so much. The current USB @&$#-up seems to be the result of "EEs try to expand line-level encoding to create an API."

This should all be solved at the negotiation layer, even if that needs to be made more complex, so that the remaining components can be simpler and reasonably-behaved.

Instead, we got something that allows each device to be a bit more electrically simple, at the cost of ballooning complexity for the ultimate use case.

USB-IF took their eye off the ball, and wrote a spec for manufacturers, without thinking about the consequences to consumers.

At some point, it's a value trade-off between {working product for use cases} and {+$2 on BoM}.

> CC system

What does "CC" stand for?

Configuration Channel

There are an added pair of pins/single wire in USB-C cables that allow the devices to a) detect the orientation of the plug and b) do extended power negotiation for the increased power capabilities of USB-C.

If you think USB is bad, try looking at all the various things that can be connected together with M.2 slots vs. the pairs of devices that will actually work together despite having the same slot. I have a degree in electrical engineering and after years I only just realized that there are actually PCIe M.2 storage devices that only support AHCI mode not NVMe.

> I have a degree in electrical engineering and after years I only just realized that there are actually PCIe M.2 storage devices that only support AHCI mode not NVMe.

To be fair, there were only a handful of those really early on when M.2 was just getting started and OS/BIOS support for NVMe wasn't universal yet. And hardly any of them were released as retail products; they were mostly OEM-only drives. All of those drives went out of production 3-4 years before the first host devices that require NVMe and can't work with AHCI started to show up: USB to NVMe bridge chips for external enclosures. So if you haven't encountered an AHCI M.2 SSD yet, you probably never will and knowing about them is just an obscure historical curiosity.