> No, backwards compatibility is competence.

Creating an IPng was always going to be complicated:

      So it's a matter of mathematical and physical fact that to expand
      the address size, you must change the protocol, and that means 
      [three] things immediately:

            You have to change the version number.

            You have to add new code to handle the new version.

      […]

            You need a coexistence technique so that updated systems, 
            with the new protocol, can connect to old systems that know 
            nothing of the new protocol.

      Two minutes of thought show that this third requirement has only 
      two solutions:

            (3A) Dual stack, in which the new machines speak both 
                 the old (IPv4) and new (IPng) protocol.

            (3B) Translation, in which something translates addresses
                 between the old and new protocols.

* https://datatracker.ietf.org/doc/html/rfc1671

For anyone curious as to the decision-making process, here are the criteria for what the IETF was looking for in an IPng:

* https://datatracker.ietf.org/doc/html/rfc1726

Here are the candidates that were floating around at the time, and the reason why the winner was chosen:

* https://datatracker.ietf.org/doc/html/rfc1752

This is very valuable, but not sure if you think it contradicts my comment.

I'm not saying that IPv6 is incompetent, or that IPv6 implementations break backward compatibility, or that the problem can be solved without breaking bc.

I'm saying that while IPv6 breaks bc itself, dual stack does not, and even full migrations can maintain bc or gracefully degraded.

In essence, not all implementations IPv6 are good, and not all migrations from IPv4 are responsible, if someone is blindly team IPv6 or blindly team IPv4 in general there's a lack of nuance.