Code change:
requires negotiation between the two endpoints using a new transport parameter, as specified in nego. <del> This proposal supports the negotiation of either the use of one packet number space for all paths or the use of separate packet number spaces per path.  While both approaches are supported by the specification in this version of the document, the intention for the final publication of a multipath extension for QUIC is to choose one option in order to avoid incompatibility.  More evaluation and implementation experience is needed to select one approach before final publication.  Some discussion about pros and cons can be found here: https://github.com/mirjak/draft-lmbdhk-quic- multipath/blob/master/presentations/PacketNumberSpace_s.pdf As currently defined in this version of the draft the use of multiple packet number spaces requires the use of connection IDs is both directions.  Today's deployments often only use destination connection ID when sending packets from the client to the server as this addresses the most important use cases for migration, like NAT rebinding or mobility events.  Further discussion and work is required to evaluate if the use of multiple packet number spaces could be supported as well when the connection ID is only present in one direction. </del> <ins> This extension uses multiple packet number spaces.  When multipath is negotiated, each destination connection ID is linked to a separate packet number space.  Using multiple packet number spaces enables direct use of the loss recovery and congestion control mechanisms defined in QUIC-RECOVERY. Some deployments of QUIC use zero-length connection IDs.  When a node selects to use zero-length connection IDs, it is not possible to use different connection IDs for distinguishing packets sent to that node over different paths.  This extension also specifies a way to use zero-length CID by using the same packet number space on all paths. However, when using the same packet number space on multiple paths, out of order delivery is likely.  This causes inflation of the number of acknowledgement ranges and therefore of the the size of ACK frames.  Senders that accept to use a single number space on multiple paths when sending to a node using zero-length CID need to take special care to minimize the impact of multipath delivery on loss detection, congestion control, and ECN handling.  This proposal specifies algorithms for controlling the size of acknowledgement packets and ECN handling in Section using-zero-length and ecn- handling. </ins> This proposal does not cover address discovery and management. Addresses and the actual decision process to setup or tear down paths

Related discussion:
text: Since NAME prodded me, we now have a PR for the "unified" proposal.
I totally agree with Christian that the issue is about "support for multipath and NULL CID", and the solution that Christian suggested looks really great! It both takes advantage of multiple spaces, and support NULL CID users without affect the efficiency of ACK arrangements. Besides, the solution is more convenient for implementations, because If both endpoints uses non-zero length cids, endpoints only need to support multiple spaces, and if one of the endpoints use NULL CID, it could use single pn space in one direction and could support NULL CID and multipath at the same time.
Very high level summary of IETF-113 discussion seems that there is interest and likely support for the unified solution (review minutes for further details).