[jmux]

The USB-C step is humongous, and hard to implement.

the complexity is high, but how else can you tell a cable that supports USB4 (40GBps) from one that’s only good for charging your phone (and everything in between)? users aren’t going to be able to tell the difference (using a cable with no data lines is already a super common issue with people getting into MCUs) so the device needs to be able to tell how much data and power the connected cable can distribute automatically.

this also why usb-c extension cables (M-F) aren’t spec complaint

it’s a real cool port, but the complexity demon is definitely present in the spec :)

[userbinator]

but how else can you tell a cable that supports USB4 (40GBps) from one that’s only good for charging your phone (and everything in between)?

By attempting to link up at the highest supported speed and downshifting if there's no valid signal? Ethernet had this figured out decades ago.

[lxgr]

USB-C doesn’t only carry USB data.

I’m not sure if e.g. Displayport even has the capacity for link training (and there are USB-C to Displayport cables that have to support legacy devices that know nothing about USB); HDMI (until 2.2 or so) definitely does not.

It’s ok to not agree with the USB-IF’s tradeoffs in their solutions, but denying the complexity of the problem space can be a hint that you don’t sufficiently understand it to pass that kind of judgement.

[theamk]

This means cable might start at speed which is too high and get horrible errors if the cable is bent.

And even with Ethernet, that autorating has plenty of downsides. I've had a cable which I accidentally nailed through, so sometimes it could only connect at 10Mbps. It took me a long time before I realized it needs to be replaced, precisely because it'd just downshift instead of throwing any errors.