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: Thanks for the summary NAME I think one point is missing in your list which is related to issue . Use of a single packet number space might not support ECN. Regarding the unified solution: I think what you actually say is that we would specify both solutions and everybody would need to implement both logics. At least regarding the "simplicity of code" argument, that would be the worst choice. If we can make the multiple packet number spaces solution work with one-sided CIDs, I'm tending toward such an approach. Use of multiple packet number spaces avoids ambiguity/needed "smartness" in ACK handling and packet scheduling which, as you say above, can make the implementation more complex and, moreover, wrong decisions may have large impact on efficient (both local processing and on-the-wire). I don't think we want to leave these things to each implementation individually.
The summary Christian made above about design comparison sounds indeed quite accurate. Besides ECN, my other concern about single packet number is that it require cleverness from the receiver side if you want to be performant in some scenarios. At the sender-side, you need to consider a path-relative packet number threshold instead of an absolute one to avoid spurious losses. Just a point I think we did not mentioned yet is that there can be some interactions between Multipath out-of-order number delivery and incoming packet number duplicate detection. This requires maintaining some state at the receiver side, as described by URL With single packet number space, the receiver should take extra care when updating the "minimum packet number below which all packets are immediately dropped". Otherwise, in presence of paths with very different latencies, the receiver might end up discarding packets from a (slower) path. I'm also preferring the multiple packet number spaces solution for the above reasons. I'm not against thinking for a "unified" solution (the proposal sounds interesting), but I wonder how much complexity this would add compared to requiring end hosts to use one-byte CIDs.
I think the issue is not really so much "single vs multiple number space" as "support for multipath and NULL CID". As noted by Mirja, there is an implementation cost there. My take is: If a node uses NULL CID and proposes support of multipath, then that node MUST implement code to deal with size of acknowledgements.