Well yeah if you made your router use 2002:1.2.3.4, your ISP advertised 2002:1.2:: on BGP, and the other ISPs agreed your ISP owns that, that would work. They didn't do that, and the spec didn't say to. They did 6to4 instead.
I understand the limitation that you can never put a 128-bit address in a 32-bit field, and one way or another two hosts and everything in between have to understand the new packet format. That didn't force them to make ipv6 its whole separate network from v4 where almost no state is shared with v4. Having separate DHCP6 vs DHCP4 was a choice, likewise with DNS, NAT, and even the routing tables. It makes the difference for service operators who would be fine adopting ipv6 but don't want it to be a big project.
Having 1.2.3.4 in v4 doesn't make ::ffff:1.2.3.4 or 2002:1.2.3.4 route to me in v6. It would route to a relay that translates/resends to v4 1.2.3.4, then it reaches my router over v4. Nobody can use that address over pure v6.
There's no one clever trick to make the transition easy, the idea is to preserve the v4 address blocks in v6. That cascades down to a bunch of different decisions, some of which include keeping NAT around. They've most likely thought of that too, and turned it down because they wanted to start with a clean slate and maybe also had some other vision of pure P2P apps.
If I have 1.2.3.4 in ipv4 world, I want 1.2.3.4 in ipv6 world instead of a random new address. I want another ipv6 host to be able to send dst=1.2.3.4 and have it go directly to my ipv6 host. 6to4 isn't comparable to that, it's for translation to/from v4 like you said.
Locked down OS and hardware, or not usable for general compute for some other reason. 20 years ago you could have a gaming PC with discs like a console, but again the console was locked down.
A game console is also locked down from the user, usually because the company is selling hardware at a loss, wants to maintain control, and wants to prevent cheating in online games. May also have exclusive games tied to the hardware.
The regular proto-to-python feels fine to me. I quit Google a while ago and have still been using protobufs, and the main things that usually make teammates wary are: 1. No way to load .proto specs at runtime (there are GH issues about this) 2. No clear and easy way to use it with HTTP/1.1. Neither is specific to Python.
Both of these might sound silly if you're used to protobufs, cause you can build little helpers for both, but plenty of people have never used protos. They would shrug proto away if there weren't someone like me to attest that it won't get in the way. It seems like Google focused on gRPC, but the real prize for adoption would've been going after the simple HTTP+JSON use cases. Like an official protobuf Express middleware.
6to4 or NAT64 isn't the same thing as what all those IPv4+/5/7/8 people want, if that's what you were referring to. You don't actually own the IPv4-mapped-V6 address, as in packets don't get routed to you, they go to a relay that was notoriously flaky.