Packet translation isn't strictly needed. Yeah in the 4-byte-addr phase, you could stick translators directly next to boxes, but probably better to just wait for at least routers to parse v5 packets natively. Then for the rest you do something like happy eyeballs to fall back from v5 to v4. The 8-byte phase only starts when v4 has been abandoned.
> I assume you mean "v4 works as normal, v5 reads A records and appends a zero byte"- congratulations, you've invented DNS64.
Yes to how v5 DNS works, but DNS64 doesn't work that way. It gives you a v4-mapped-v6, your packet goes there, and NAT64 translates the packet to v4. So you're still relying on ipv4, plus it takes a notoriously unpredictable route to reach the NAT64.
You could say that ipv5 is kinda like if you made v4-mapped-v6 the only way to use ipv6, didn't do NAT64, and then expanded those to >4 bytes at a later time.
> why hasn't it been done already?
It must've been considered. I'm guessing it's one or more of the IETF way back in 1998:
1. not wanting to maintain the old ipv4 blocks going forward, rather start with a clean slate to build more efficient routes
2. seeing the ipv6 design with SLAAC etc as more elegant, which in some ways it is, but some parts also didn't age well, hence the privacy extensions added later
3. thinking people would be more willing to switch
4. overestimating how many people wanted P2P connections; they were originally recommending v6 default-allow inbound, then later said consumer routers should default-deny, but this is still less idiotproof than NAT