Change:
information.  The peer is expected to send more PATH_CHALLENGE frames as necessary to evoke additional PATH_RESPONSE frames. <del> 8.5. </del> <ins> 8.2.3. </ins> Path validation succeeds when a PATH_RESPONSE frame is received that contains the data that was sent in a previous PATH_CHALLENGE frame.

Discussion:
I tried to be conservative about changes, but there were a few paragraphs I thought should be moved. Otherwise, the changes are minimal. URL is the commit that adds a paragraph to clarify the main confusion on
Something to look into...
NAME I was previously finding the text confusing and potentially contradictory. When I read it all at once, I believe I understand the intent, but hopefully this change makes each portion clearer and less dependent upon adjacent sections. There's probably a bit more worth doing, but at some point I'm willing to call it good enough.
We decided to only specify client-initiated connection migration in QUIC v1. The section about Connection Migration mostly talks about endpoint and peer though, which makes it really hard to parse. I haven't implement migration yet in quic-go, and reading this section confused me at multiple places. I believe that specifying the role of the endpoint would make things a lot clearer, and could offer to come up with a PR.
I don't think this is worth doing, but would look at a PR.
To clarify, this would only apply to connection migration, not the path validation section that immediately precedes it.
NAME The idea was to keep the migration mechanisms generic, since they can be applied to either endpoint. However, this isn't adequate if we support migration at both ends, since you'd have to deal with other situations, such as simultaneous migration. v1 simply limits the scope of where these mechanisms ought to be applied. There's value in that, but I understand your reservations. Like NAME I'm not keen to follow the premise of this issue, but I'd be open to a PR. I'd also be open to clarifying the parts you found confusing.
Looking at that section again, I don't believe I want to do anything about this issue.
This choice was deliberate. Maybe it's nicer, but now is not really a good time.
Update: I thought simultaneous path validation wasn't necessary, but it looks like I misunderstood. Changing this to an editorial issue so I can re-read this text and hopefully make it clearer. I believe this is already implied, but I couldn't find it stated anywhere. I think it'd be ideal to set expectations that servers are not expected to validate multiple paths at the same time. Validating multiple paths seems like a plausible feature for multipath, but adds undue complexity for connection migration.

Does that imply that a client can only probe a single path at a time? What's the time it has to wait after apparent unsuccessful probing of one path until it can probe the next?
NAME I'm not sure if I agree. It has been my assumption that a server is expected to respond to clients probing multiple paths concurrently. Note that in , we added the following text:
Hmm, I didn't think this was already implied. You're not expected (or allowed) to send non-probing packets on multiple paths, but you can certainly get probes in from multiple different remote endpoints. This is somewhat necessary if we're to be resilient to the various packet racing attacks -- if an attacker can cause you to be upset about a packet coming in from a different destination then they can really mess you up.
I'm a bit confused about why a client needs to probe multiple paths simultaneously, given we have connection migration, not multipath. To me, it just adds complexity. I guess I can just give out a single CID to mitigate the issue, but do we really expect servers to correctly implement probing on multiple paths? What if they all succeed? A client can still only use one. NAME can you clarify the packet racing issue a bit more or point me to text that already does? I'd like to draw a state transition diagram for path validation, but if we can have multiple paths being validated at once, I'm not sure that's practical.
NAME So the scenario is that a client is using one path and has 2 or more new ones available? I've heard future hardware could make that possible, though I've never seen that case myself. The short of this is now that we're trying to move to IETF QUIC style connection migration and path validation, and I'm finding it fairly confusing.
I think there's a pretty big distinction between probing a path to establish the potential for connectivity and migrating the connection to that path. For example, I would not be at all surprised if a client were to probe all available paths and choose the "best" one to migrate to when the need arises (often, although not always, there is some warning that conditions are worsening on the current path which provides the opportunity to evaluate alternatives).

That said, I think a large part of the reason to allow probing on multiple paths is to avoid requiring synchronization of a shared understanding as to the state of current probes. We don't want to add a bunch of machinery to establish failure of a probe on a different path. So even if we don't think that a client would ever intentionally probe multiple paths, if a client probes one path and hears no response, it seems completely reasonable to think that it would switch and probe a different path if it had one available. If it turns out that there was just some delay for that initial path, say it had a 1.5s RTT, now the server is going to think the client probed two paths at the same time, when in reality the client thinks it's just talking to one. It also doesn't seem particularly harmful to allow this? As NAME noted, there's some good text in there about limiting state required on the server, and of course path validation can happen at any time, so it seems completely reasonable to "forget" that any given path was validated if a client probes and then doesn't end up using the path. (Note that you'd likely want to retire the CID used on that path, so as to replace it with a new one when you did that forgetting, which also serves as a nice heuristic for the other endpoint to say "oh, hmm, they don't think they're talking to me over there", but we can dig into that later.) The packet racing thing is a reference to and the previous section. This led us to require endpoints to validate both the current and the new path when it changes, which conveniently provokes some traffic to reconfirm the active path and makes it more difficult to disrupt a connection that's gone idle. While technically this is only discussing one "new" path and then the old path being validated at the same time, it seems as though it would be trivial for such an attacker to convince an endpoint that it was seeing "probes" (since we've discussed that it's not that difficult to identify a probing packet as an observer) from multiple paths and therefore be quite upset if such behavior were restricted. I'm not saying this happens all the time, but it seems pretty reasonable to have a Wi-Fi interface and then a dual SIM device with multiple cellular interfaces.

Overall, it seems as though (even if this isn't crazy common) it's not unreasonable to expect that this behavior might happen, and it doesn't seem like there's a big benefit to restricting it, nor harm in allowing it, beyond the existing text reminding endpoints to be careful with the amount of state they're willing to allocate to any individual client (which is a thing outside of any probing/migration concept anyways).
+1 to what NAME says. The resolution of (which ended up as PR ) was that a server has to remember state of N paths where N is the number of CIDs active at one time. As NAME says, a client cannot tell when a server thinks that it received two probes concurrently. Therefore, it is very tricky to have this kind of restriction within a specification that allows clients to retain multiple backup paths.
I agree with NAME and NAME here. If a client sends a probe on interface A, and then interface A disconnects and then interface B appears immediately, the client should be able to probe on interface B even though to the server will receive two independent probes at roughly the same time. Servers need to be able to handle multiple concurrent probes in order for migration to be reliable.
Note that while the server needs to respond to the probes (so the client can validate the paths), I don't think there's any requirement that the server continue to regard all those paths as validated. When the client actually migrates, if the server wants to treat the migration as an unvalidated path and initiate validation again, that seems fine.
Well, the paths aren't validated until the server explicitly validates them, so it seems like the cost is pretty minimal until the server decides to engage resources for that path. The server can also respond on the old path if the client is just probing.
NAME do you want to think about how you reached your conclusion here and see if there is something we can do to avoid that? It seems to me that the cost to a server is limited by how many paths it wants to probe, not how many the client probes, so the state is well managed. It's a little less neat if the client actively migrates multiple times. But I would say that the server can abandon probes to keep the number of active probes down to at most 2 (one for the most recent validated path, one for the most recent active path).

Is that something we need to explain more thoroughly?
I have read this text quite a bit, but not end-to-end in quite a long time, so I believe that's the cause of my confusion. I'm planning to re-read all the path validation and connection migration text and I'll send out a PR if there are points that I think I are unclear.
NAME have you had a chance to do this?
Unfortunately, not yet.
Note that man-on-the-side attacker can take a valid packet and resend it from a different address. The crypto does not protect against that. If the attacker somehow isolates probe packets, the server will end up receiving probes from a variety of endpoints. Better not do something silly in that condition.
Would people please take a final look at the PR?
A few comments, but pretty close.