Back in the old days we needed to make an Ethernet Crossover Cable to get this to work.
Modern ethernet supports Auto MDI-X, which manages that automagically for you.
Modern ethernet supports Auto MDI-X, which manages that automagically for you.
To be fair, I don't know why USB had to wait until a few years back to stop acting quantum with its C incarnation. As you know a USB interface with two possible orientations will require at least three insertion attempts.
I grew up with RS232 and expected better. I had to wait quite a long time. USB C is quite good.
Old 10base-T ethernet used one pair of wires for transmit, and another pair of wires for receive (and the other 2 pairs? they did nothing at all!). This worked for the usual case of plugging computers into a hub.
It was Good Enough, and it fit the style of the time.
Could it have been done better? Sure! But that would have added complexity, and adding complexity means even more cost.
And all of this Ethernet hardware was already very expensive. A person who had enough money get into 10base-T hardware probably also had enough money to get a crossover cable in their hands.
The expense is why people like you and I grew up with using RS-232: That was the affordable way to get computers to talk together.
(Let me guess: You also had a run-in with 10base2 once that became cheap-enough, and you also spent way too long soldering together a cable to get PLIP going between a pair of computers)
---
Anyway, auto MDI/MDI-X is pretty much a solved problem these days. At this point there are surely people reading these pages who have been doing stuff with computers and Ethernet for their entire lives and have never needed to know what a crossover cable is.
This, too, is Good Enough. :)
Hilliers had two sites with a road in between. We had an IBM System/36 (with a dicky fan which needed prodding in summer or the box would shutdown due to overheating). Once we surrounded it with bags of solid CO2 in a really hot summer to keep it running.
The two sites were linked with synced modems on standard phone lines. Normally serial lines are async but these things ran as sync. Even back then a change would take milli-seconds to perhaps deci-seconds to process so why on earth require sync! There will be a reason and it will have been forgotten by today's slapdash approach to nearly everything.
The spec works fine. It really does. It is complete and functional in its ambidextrous nature.
The usual problems happen when people and/or companies don't spend the time to understand it, and/or find merit in shaving a few tenths of a cent on the BOM. In these instances, we get out-of-spec things that quite predictably work in out-of-spec ways.
The implementers of the spec are sometimes errant nimrods, though. Errant nimrods can bring a bad time to any party they decide to be involved in. This can be particularly problematic when they're weaponized by having their own manufacturing divisions.
(And that's not new: Errant nimrods have been in charge of manufacturing fucked up devices for as long as we've had devices for them to fuck up. Probably centuries, by now; maybe longer.)
But only one of these groups is responsible for supplying actual-fucking-hardware to the group that simply uses it.
And sometimes, that group consists of errant fucking nimrods.
Compared to that, 10BaseT was easy mode. Someone who could manage to keep a coax network working had no difficulty making a cross cable.
By the time switches came along and then 100BaseT, auto MDI switching was no longer expensive and pretty standard. When gigabit came it actually became a requirement of the standard.