Code change:
The transmission of QUIC packets on a regular QUIC connection is regulated by the arrival of data from the application and the <del> congestion control scheme.  QUIC packets can only be sent when the congestion window of at least one path is open. Multipath QUIC implementations also need to include a packet </del> <ins> congestion control scheme.  QUIC packets that increase the number of bytes in flight can only be sent when the congestion window allows it.  Multipath QUIC implementations also need to include a packet </ins> scheduler that decides, among the paths whose congestion window is <del> open, the path over which the next QUIC packet will be sent.  Many factors can influence the definition of these algorithms and their precise definition is outside the scope of this document.  Various packet schedulers have been proposed and implemented, notably for Multipath TCP.  A companion draft I-D.bonaventure-iccrg-schedulers provides several general-purpose packet schedulers depending on the application goals. Note that the receiver could use a different scheduling strategy to send ACK(_MP) frames.  The recommended default behaviour consists in sending ACK(_MP) frames on the path they acknowledge packets.  Other scheduling strategies, such as sending ACK(_MP) frames on the lowest latency path, might be considered, but they could impact the sender with side effects on, e.g., the RTT estimation or the congestion control scheme.  When adopting such asymetrical acknowledgment scheduling, the receiver should at least ensure that the sender negotiated one-way delay calculation mechanism (e.g., QUIC- Timestamp). </del> <ins> open, the path over which the next QUIC packet will be sent.  Most frames, including control frames (PATH_CHALLENGE and PATH_RESPONSE being the notable exceptions), can be sent and received on any active path.  The scheduling is a local decision, based on the preferences of the application and the implementation. Note that this implies that an endpoint may send and receive ACK_MP frames on a path different from the one that carried the acknowledged packets.  A reasonable default consists in sending ACK_MP frames on the path they acknowledge packets, but the receiver must not assume its peer will do so. </ins> 7.5.

Related discussion:
text: I can certainly provide them an API to do that, but this is basically research. And then, affinity applies to stream frames, but whether it should be applied to control frames is debatable. I am concerned that the guidance that we provide will be so generic as not to be useful, while still requiring long debates and delaying the publication of the draft. I think guidance is best provided in research papers, and possibly in text books.
I agree we shoukd avoid the potential time sink. I wasn't suggesting guidance but rather a fairly succinct statement like "The path that frames are sent on is a local choice, which could effect the behavior or performance of the QUIC transport or delivery of application data. There is no guidance provided by this document on strategies for path selection for frames beyond the control frames for the multipath extension itself." And perhaps gathering consensus on that now avoids people asking the question in later review rounds.
NAME I agree. Your proposal is basically equivalent to my suggestion that "if we do say something, just say that these frames can be sent on any valid path, based on preferences of the application and the implementation." Your text is good.
Sorry, I did read your comment and immediately paged it out. Credit to you for proposing that option earlier
Looks good, but the description of congestion is imprecise. Either drop it or fix it.