Code change:
idle timeout".  When only one path is available, servers MUST follow the specifications in QUIC-TRANSPORT. <del> When more than one path is available, servers shall monitor the arrival of non-probing packets on the available paths.  Servers SHOULD stop sending traffic on paths through where no non-probing packet was received in the last 3 path RTTs, but MAY ignore that rule if it would disqualify all available paths.  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. </del> <ins> When more than one path is available, hosts shall monitor the arrival of non-probing packets and the acknowledgements for the packets sent over each path.  Hosts SHOULD stop sending traffic on a path if for at least max_idle_timeout milliseconds (a) no non-probing packet was received or (b) no non-probing packet sent over this path was acknowledged, but MAY ignore that rule if it would disqualify all available paths.  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. </ins> Server MAY release the resource associated with paths for which no non-probing packet was received for a sufficiently long path-idle

Related discussion:
text: I would suggest to rewrite the text as follows (I removed Server, because I think the recommendation should be generic): When more than one path is available, hosts shall monitor both the arrival of non-probing packets and the acknowledgements for the packets sent over each path. Hosts SHOULD stop sending traffic on paths whether either: (a) no non-probing packet was received in the last 3 path RTT or (b) no non-probing packet sent over this path was acknowledged during the last 3 path RTT, but MAY ignore that rule if it would disqualify all available paths. 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].
The word "either" means that STOP sending becomes true If either (a) is true or (b) is true. If I understand correctly, the actual meaning is to use the word "both" here, instead. So stop sending if both (a) no non-probing packets received and (b) no packets was acknowledged.
Yes, I think this is a good clarification and yes "either" might be confusing here.
I commented on the PR. I don't like the idea that receivers would have to stop acknowledging packets in order to signal preference to not use a path. We need to think that a little more.
So we have a choice: either say that nodes should regularly send non-probing packets over the path that they want to keep using, or if we don't want that, accept the idea that acks on other paths show continuity, and require "abandon path" to terminate a path that is otherwise working, acknowledges packets, etc..
Yes, I think the second option is what we are aiming for with the new text. Stopping ack'ing packets to stop someone sending on a path is wrong and is something you should never do. If you receive a packet successfully you should ack it (also because that would otherwise confuse congestion control). But we have the abandon frame exactly for that case. However, it also seems wrong to me to require sending acks on the same path taen the data is received.