The pinout for full and half duplex is the same, the behavior is just different.
If you get traffic on the RX pins when you're sending on the TX pins, in full duplex, that's great. In half duplex, it's a collission and you stop sending your current packet and send a jam signal instead through the minimum packet time.
In 10base2, the RX check is more nuanced, because it's reading from the same bus that TX happens on, collision is only signalled if the RX differs from TX. In 10baseT, I think (but again, would love to be corrected), the expectation is that an ethernet hub will isolate a sending port from receiving its own transmission to the shared bus inside the hub, and of course switches are switches.
For the simple case of two Ethernet devices connected with a crossover cable, there is no possibility of actual collision, but if they run in half-duplex mode, recieving a packet while sending will be processed as a collision anyway.
If you connect only one pair, you can connect RX to RX and TX doesn't go anywhere, TX to TX and TX goes (subject to collissions), but nobody listens, or Peer A TX to Peer B RX and get a one way connection; peer B may detect link up because it gets link pulses, but peer A won't. I'm not sure what Auto MDI-X does in that situation, but it still won't work.
Autonegotiaton usually doesn't do anything smart about failing pins or poor connections either. If you've got two pair connected, you can autonegotiate (at 1Mbps, with the 10baseT link pulses) to the best connection offered by both ends, which will then fail to work if you negotiated to GigE and only have two pairs, or you negotiated to 100M and the cable is really terrible. It's getting somewhat common for OS drivers to detect this negotiation succeeds/connection doesn't behavior and restart the negotiation with fewer options though.
If I have some time today, I'll make a single pair cable and confirm, but if it were as easy as you said, there would probably be a web page telling people how to do it.
I could swear I remember running over a single pair, but it's been a few decades so I might be wrong about this!
If 10bT really does always use 4 pins then I wonder what would happen if tx+/rx+ and tx-/rx- were shorted? I wouldn't be surprised if there's no page illustrating it because why would you ever want to?
If you've got a burried run of two pair wire that you're running ethernet on, but something happens and one pair goes bad, it might be nice to use the working pair, because trenching is a pain. Or maybe you have two pair, but you really want a phone line and ethernet (and ethernet+voip won't work). Etc lots of cases where rewiring is hard, but you don't have enough wires.
If you get traffic on the RX pins when you're sending on the TX pins, in full duplex, that's great. In half duplex, it's a collission and you stop sending your current packet and send a jam signal instead through the minimum packet time.
In 10base2, the RX check is more nuanced, because it's reading from the same bus that TX happens on, collision is only signalled if the RX differs from TX. In 10baseT, I think (but again, would love to be corrected), the expectation is that an ethernet hub will isolate a sending port from receiving its own transmission to the shared bus inside the hub, and of course switches are switches.
For the simple case of two Ethernet devices connected with a crossover cable, there is no possibility of actual collision, but if they run in half-duplex mode, recieving a packet while sending will be processed as a collision anyway.
If you connect only one pair, you can connect RX to RX and TX doesn't go anywhere, TX to TX and TX goes (subject to collissions), but nobody listens, or Peer A TX to Peer B RX and get a one way connection; peer B may detect link up because it gets link pulses, but peer A won't. I'm not sure what Auto MDI-X does in that situation, but it still won't work.
Autonegotiaton usually doesn't do anything smart about failing pins or poor connections either. If you've got two pair connected, you can autonegotiate (at 1Mbps, with the 10baseT link pulses) to the best connection offered by both ends, which will then fail to work if you negotiated to GigE and only have two pairs, or you negotiated to 100M and the cable is really terrible. It's getting somewhat common for OS drivers to detect this negotiation succeeds/connection doesn't behavior and restart the negotiation with fewer options though.
If I have some time today, I'll make a single pair cable and confirm, but if it were as easy as you said, there would probably be a web page telling people how to do it.