Change:
12.2. <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 according to the preference expressed in these frames.  PATH_STATUS frames are formatted as shown in fig-path-status-format. PATH_STATUS Frames contain the following fields: Path Identifier: An identifier of the path, which is formatted as shown in fig-path-identifier-format.  Exactly the same as the definition of Path Identifier in {#path-abandon-frame}. Path Status sequence number: A variable-length integer specifying the sequence number assigned for this PATH_STATUS frame.  The sequence number MUST be monotonically increasing generated by the sender of the Path Status frame in the same connection.  The receiver of the Path Status frame needs to use and compare the sequence numbers separately for each Path Identifier. Available values of Path Status field are: 1: Standby 2: Available Endpoints use PATH_STATUS frame to inform the peer whether it prefer to use this path or not.  If an endpoint receives a PATH_STATUS frame containing 1-Standby status, it SHOULD stop sending non-probing packets on the corresponding path, until it receive a new PATH_STATUS frame containing 2-Available status with a higher sequence number referring to the same path. Frames may be received out of order.  A peer MUST ignore an incoming PATH_STATUS frame if it previously received another PATH_STATUS frame for the same Path Identifier with a sequence number equal to or higher than the sequence number of the incoming frame. PATH_STATUS frames SHOULD be acknowledged.  If a packet containing a PATH_STATUS frame is considered lost, the peer should only repeat it if it was the last status sent for that path - as indicated by the sequence number. 12.3. </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

Discussion:
For issue
I agree with this point. For the receiver side, endpoint MAY ignore this frame if it would cause all the paths unavailable. I updated the description.
I believe stand-by (or backup) has been useful in MPTCP. This is not really about scheduling because all it says is: I won't use this path actively(yet) but please leave it open.
IMHO, this is a (simple) form of path prioritization. I'm not sure it should be part of the current. We could delegate this point to an "advanced" path management draft.
I agree that this should not be in the core. Let's start by assuming that all established paths can be used. We will then be able to add mechanisms to indicate that some existing paths should not currently be used. In MPTCP we only had limit messages to do this. In QUIC, we will have more flexibility in the definition of frames to encode such information if needed.
Okay, actually there might be two different signals here: One is "please do not use this path as long as you have others" but the other is "please keep this path open even if I don't use it". I agree we don't need the first one but I thought the second one might be useful because otherwise if no packets are received on a path the other end might assume the path to be closed after an idle time, no?
One problem is NAT timeout when we want to keep a path open but do not send any traffic. To solve this, we may want to send "ping" at a very low frequency to keep that path alive. Suppose if we don't have a stand-by state (which I think we should have eventually), but we do employ this ping mechanism to keep that path alive, does it solve Mirja's problem as now the other end won't close that path because it receives some "ping"s at a very low frequency?
I indeed think that we should have some mechanism (like sending a PING frame) to avoid some "path idle timeout".
Do we need any more text in the draft or can we just close this issue?
The current text in Section 3.2.3 ("To avoid idle timeout of a path, endpoints can send ack-eliciting packets such as packets containing PING frames Section 19.2 of [QUIC-TRANSPORT] on that path to keep it alive.

Sending periodic PING frames also helps prevent middlebox timeout, as discussed in Section 10.1.2 of [QUIC-TRANSPORT].") is fine for me.
This is still much more expensive than MPTCP's backup subflows since we send a PING frame every N rtts, with N being close to 3.
I don't see many QUIC applications relying on keep-alive. For example, when studying DNS over QUIC, we concluded that it was much easier to use resumption and 0-RTT than to try to keep the paths open through NAT. I also think the issue is asymmetric: Servers have no good way to know that a path that has been idle for some time is still valid. The client might have moved, or the NAT binding might have changed. If servers send traffic on an idle path, there is a high risk that the traffic will be lost. The default should be, "silent close on idle". Clients typically do not have such limitations, because their traffic will force a new NAT binding if one is missing. There are mitigating strategies, such as only sending redundant traffic on suspect paths, but we probably don't need to discuss that here.
QUIC applications rely less on keep-alive (as you have 0-RTT resumption), however, I think the situation is different for multipath. If you have multiple paths available, you might still decide to only send data on one path at a time, e.g. you want to have a hot stand-by, meaning you already open a new path but didn't decide to use it yet, or want to be able to switch back to an "old" path anytime.
Do we need further text here or can we close this issue?
Actually thinking about this further I still think we should have at least one signal to tell the other end that a path should not be used. This is the typical handover case: a client opens both a wifi and a cellular path, also sends keep-alive on the cellular path to make sure one can switch over quickly. However, when it requests data from the server, the server doesn't know which path to use or that it should actually not use one of path as it is more costly. Therefore I think we need a signal to tell the other end that a path should not actively be used for sending data (as long as another path is still available).

NAME I agree that having a signal for stand-by is beneficial. Actually, we did have the standy-by signal with the PATHSTATUS frame in draft-liu. The PATHSTATUS frame signals three status: (1) abandon, (2) stand-by, and (3) available. PATHSTATUS Frame { Type (i) = TBD-03 (experiments use 0xbaba03), Path Identifier (..), Path Status sequence number (i), Path Status (i), Path Priority (i), } When the three drafts were merged, the PATHSTATUS frame was replaced by the current PATH_ABANDON frame, as at that time we wanted the first version to focus on the very basic features. I think we can put the stand-by status back if it proves to be a general requirement.
The stand-by status in draft-liu is used to explicitly inform the sender not to schedule packets on this path, but endpoints can keep the path context not to be removed. Once the endpoints need to use this path again, they can send PATH_STATUS(active) to update the status, and send packets on the path immediately without path validation and other preparation for this path. We can discuss about whether if we need to add the mechanism into the working group version.
At IETF-113 there was general support for this idea. Next step: write PR
The PATHSTATUS frame as described in PR is a rather generic way to update path information. Actually not sure if we need this at this point. I was assuming that indicating a path to be a stand-by or back-up path is a rather static information. E.g. if your mobile link is more expensive, this is static and will not change over the life time of the path. As such another option would be to signal this information during path initiation, e.g. creating an MPPATH_CHALLANGE frame that contains a flag.
It is generally preferred to defined composable frames, rather than create a special purpose version of an existing frame. I would combine Status & Challenge in a single message rather than modifying challenge. But we have to understand what happens if a challenge is lost, repeated, etc. I am also not sure that the 'status' is "once and forever". I could see the status evolving over time, and alternating between standby and available. But we need to add a bit to the specification.

In particular: is there a default status when no status frame have been received on a path? does the status change if the peer starts sending non-probing frames on the path? can both client and server change the status of a path? do frames affect both directions of a path?
Yes, available. However, I wouldn't really call this a default status, because this info is a signal to the other end in order to give a recommendation if that should be sent on this path or not, but the fine sending decision is a local decision. If this info is not available, the sender has to base its decision on other (local known) criteria. No. Yes and no. The status tells the other end if or if not it should send data on the path. So effectively it impacts only one direction of the path as the other direction is a local decision. No. As I just said. This is a recommendation for the sender, however, if the sender follows that recommendation is effectively also a local decision. Again, I think we should at this point really just focus on the standby function and not make this too generic because that makes is more complicated.
NAME the current default status is "standby until the client has sent non probing frames, available after that" -- per RFC 9000. I would think that the client sending a status frame overrides that, since "status" is not "probing", but it is probably worth specifying. Similarly, I do agree with the "unilateral" view of status that you are presenting, "just tell the other end whether to send on that path of not." But it is worth specifying.
Okay, if we agree that we want a separate PATH_STATUS frame then I think PR is ready to merge. NAME and NAME can you review and approve PR ? Thanks!
Sounds good to me.Looks good.