Code change:
multipath negotiation is ambiguous, they MUST be interpreted as acknowledging packets sent on path 0. <del> Endpoints negotiate the use of one packet number space for all paths or separate packet number spaces per path during the connection handshake nego.  While separate packet number spaces allow for more efficient ACK encoding, especially when paths have highly different latencies, this approach requires the use of a connection ID. Therefore use of a single number space can be beneficial when endpoints use zero-length connection ID for less overhead. </del> 7.1. <del> If the multipath option is negotiated to use one packet number space for all paths, the packet sequence numbers are allocated from the common number space, so that, for example, packet number N could be sent on one path and packet number N+1 on another. ACK frames report the numbers of packets that have been received so far, regardless of the path on which they have been received.  That means the senders needs to maintain an association between sent packet numbers and the path over which these packets were sent.  This is necessary to implement per path congestion control. When a packet is acknowledged, the state of the congestion control MUST be updated for the path where the acknowledged packet was originally sent.  The RTT is calculated based on the delay between the transmission of that packet and its first acknowledgement (see compute-rtt) and is used to update the RTT statistics for the sending path. Also loss detection MUST be adapted to allow for different RTTs on different paths.  For example, timer computations should take into account the RTT of the path on which a packet was sent.  Detections based on packet numbers shall compare a given packet number to the highest packet number received for that path. </del> <ins> If a zero-length connection ID is used, one packet number space for all paths.  That means the packet sequence numbers are allocated from the common number space, so that, for example, packet number N could be sent on one path and packet number N+1 on another. In this case, ACK frames report the numbers of packets that have been received so far, regardless of the path on which they have been received.  That means the senders needs to maintain an association between sent packet numbers and the path over which these packets were sent.  This is necessary to implement per path congestion control, as explained in zero-length-cid-loss-and-congestion. Further, the receiver of packets with zero-length connection IDs should implement handling of acknowledgements as defined in sending- acknowledgements-and-handling-ranges. ECN handing is specified in ecn-handling, and mitigation of the RTT measurement is further explained in ack-delay-and-zero-length-cid- considerations. If a node does not want to implement this logic, it MAY instead limit its use of multiple paths as explained in restricted-sending-to-zero- length-cid-peer. </ins> 7.1.1. <ins> If zero-length CID and therefore also a single packet number space is used by the sender, the receiver MAY send ACK frames instead of ACK_MP frames to reduce overhead as the additional path ID field will anyway always carry the same value. </ins> If senders decide to send packets on paths with different transmission delays, some packets will very likely be received out of order.  This will cause the ACK frames to carry multiple ranges of

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).