Original text:
8.1. <del> The PATH_ABANDON frame informs the peer to abandon a path.  More complex path management can be made possible with additional extensions (e.g., PATH_STATUS frame in I-D.liu-multipath-quic ). </del>  PATH_ABANDON frames are formatted as shown in fig-path-abandon- format. PATH_ABANDON frames SHOULD be acknowledged.  If a packet containing a PATH_ABANDON frame is considered lost, the peer SHOULD repeat it. <del> PATH_ABANDON frames MAY be sent on any path, not only the path on which the referenced Destination Connection ID is used. 8.2. </del>  PATH_STATUS Frame are used by endpoints to inform the peer of the current status of one path, and the peer should send packets if it was the last status sent for that path - as indicated by the sequence number. <del> 8.3. The ACK_MP frame (types TBD-00 and TBD-01; experiments use 0xbaba00..0xbaba01) is an extension of the ACK frame defined by QUIC- TRANSPORT.  It is used to acknowledge packets that were sent on different paths using multiple packet number spaces.  If the frame type is TBD-01, ACK_MP frames also contain the sum of QUIC packets with associated ECN marks received on the connection up to this point. ACK_MP frame is formatted as shown in fig-ack-mp-format. Compared to the ACK frame specified in QUIC-TRANSPORT, the following field is added. The sequence number of the Connection ID identifying the packet number space of the 1-RTT packets which are acknowledged by the ACK_MP frame. </del> 9. Multipath QUIC transport error codes are 62-bit unsigned integers

Reviewer comments:
The ACKMP text does not change, it just comes before PATHABANDON and PATHSTATUS. The rationale is that 1) the new order follows the encoding numbering (lowest to highest), and 2) the ACKMP is a critical frame, the PATHABANDON is an important one yet still "indicative" (it suggests the peer to abandon this path) and the PATHSTATUS frame is an indicative one.
Just to not forget this, but this is mostly editorial. Probably present first the ACKMP frame, and then PATHABANDON and PATHSTATUS Drop reference to I-D.liu-multipath-quic as the PATHSTATUS frame is now integrated in the draft. Based on and , and If we agree on , we could also drop the text in PATh_ABANDON stating that on any path, not only the path on which the referenced Destination Connection ID is used.
OK. It's reasonable.

Revised text:
8.1.  <ins> The ACK_MP frame (types TBD-00 and TBD-01; experiments use 0xbaba00..0xbaba01) is an extension of the ACK frame defined by QUIC- TRANSPORT.  It is used to acknowledge packets that were sent on different paths using multiple packet number spaces.  If the frame type is TBD-01, ACK_MP frames also contain the sum of QUIC packets with associated ECN marks received on the connection up to this point. ACK_MP frame is formatted as shown in fig-ack-mp-format. Compared to the ACK frame specified in QUIC-TRANSPORT, the following field is added. The sequence number of the Connection ID identifying the packet number space of the 1-RTT packets which are acknowledged by the ACK_MP frame. 8.2. The PATH_ABANDON frame informs the peer to abandon a path. </ins> PATH_ABANDON frames are formatted as shown in fig-path-abandon- format. PATH_ABANDON frames SHOULD be acknowledged.  If a packet containing a PATH_ABANDON frame is considered lost, the peer SHOULD repeat it.  <ins> 8.3. </ins> PATH_STATUS Frame are used by endpoints to inform the peer of the current status of one path, and the peer should send packets if it was the last status sent for that path - as indicated by the sequence number.  9. Multipath QUIC transport error codes are 62-bit unsigned integers