Change:
9.1. <del> The PATH_ABANDON frame informs the peer to abandon a path, and release the corresponding resources.  An endpoint uses the sequence number of the CID used by the peer for PATH_ABANDON frames (describing the sender's path identifier).  More complex path management can be made possible with additional extensions (e.g., PATH_STATUS frame in I-D.liu-multipath-quic ). </del> <ins> The PATH_ABANDON frame informs the peer to abandon a path.  An endpoint uses the sequence number of the CID used by the peer for PATH_ABANDON frames (describing the sender's path identifier).  More complex path management can be made possible with additional extensions (e.g., PATH_STATUS frame in I-D.liu-multipath-quic ). </ins> PATH_ABANDON frames are formatted as shown in fig-path-abandon- format.

Discussion:
Please carefully review the text about abandon frames on the last active path. This is new and maybe not what you intended, however, because of potential crossing of abandon frames from each direction (as mentioned by NAME in the issue), I don't think receiving an abandon frame on the last active path should be a protocol violation.
The text says that both endpoint can send an abandon frame. However, if I understand the current text correctly it only says that the receiving peer of that frame can remove its state as the sender of the abandon frame indicated it will not send any more packets ion that path. However, the sender of the abandon frame can't remove its state until it also receives an abandon frame from the other end. That would mean a path can "half-open"... Do we need to say something that that the receiver of an abandon frame SHOULD also send an abandon frame in response? Or MAY? Or MUST? Or is the path considered completely closed as soon as an ACK for the packet containing the abandon frame is received? In this case we need to say that when an abandon frame is received, the receiver MUST not use that path anymore. I think we need to clarify that! Please provide a PR or let me know what the intention was and I can write something!
For me, ABANDONPATH means "please stop sending on that path, I may soon stop listening". The peer should definitely stop sending on that path. It may want to keep listening for a short time, because some packets may still be sent out of order. It may also want to keep some context to process acknowledgement of packets previously sent on that path. The general guidance is to to wait for something like 3xRTO before dropping path management resource. I don't think that we need symmetry, that both peers have to abandon the path before they can release resource. But we have to solve a potential path suicide problem. Suppose we have two paths, peer 1 abandons path , peer 2 abandon path . Now we have zero path, and the connection is closed -- unless the client promptly opens a new path . My original intention is that only the client ever sends an ABANDONPATH, since only the client can initiate a new path, which dodges the path suicide issue.
Good questions!

For me, the issue is that when an endpoint decides to close a path, it is probably due to that the path condition is getting worse, which also means that further communication on that path may fail. When we use non-zero CID, as we should have at least one path that is working (if no path is working, the connection will be closed), and we are not constraint to send PATHABANDON frame on the same path that we want to close, the sender should be able to receive the ACK of PATHABANDON. But when we use null CID, we use pathidtype 0x02, which refers to the path where the packet is coming from, and hence, we are constraint to send PATHABANDON on the same path we want to close. In such a case, it is likely that the ACK of PATHABANDON will not be received, resulting in the "half-open" problem. Therefore, we should say sth like "when the sender moves into the "ABANDONSENT" state, and after 3RTO, it should close the path even if it hasn't seen the PATHABANDON sent from its peer".
Also, regarding when a path is considered completely closed, the current intention is that a path is considered closed when both the sender-side and the receiver-side resources of that path are released. The sender-side resources can be readily released when PATHABANDON is acked (We may need to retransmit the pathabandon). The receiver-side resources are released when the RETIRECID frame is received. However, when zero-CID is used, it is possible that an endpoint is not going to receive any RETIRECID frames, so the receiver-side resources are released 3RTO after sending out the PATH_ABANDON.
I created PR . I think this is the biggest issue we need to address and agree on before submission of -00. So please review NAME NAME NAME !
Sounds good. I think the next feedback will come once we have implemented and tested the feature.