Change:
Receiving a packet from a new peer address containing a non-probing frame indicates that the peer has migrated to that address. <del> An endpoint only changes the address that it sends packets to in response to the highest-numbered non-probing packet.  This ensures that an endpoint does not send packets to an old peer address in the case that it receives reordered packets. In response to such a packet, an endpoint MUST send subsequent </del> <ins> If the recipient permits the migration, it MUST send subsequent </ins> packets to the new peer address and MUST initiate path validation (migrate-validate) to verify the peer's ownership of the address if validation is not already underway. <ins> An endpoint only changes the address to which it sends packets in response to the highest-numbered non-probing packet.  This ensures that an endpoint does not send packets to an old peer address in the case that it receives reordered packets. </ins> An endpoint MAY send data to an unvalidated peer address, but it MUST protect against potential attacks as described in address-spoofing and on-path-spoofing.  An endpoint MAY skip validation of a peer

Discussion:
Reading over the text in the sections NAME commented on, it feels like the heart of the conflict is this: Some sections say that servers don't migrate in this version of QUIC. This section speaks generically about what an implementation MUST do if the peer migrates, suggesting clients have to obey them if the server does migrate. Additionally, we've discussed mitigations to other issues (e.g. ) in which a server might consider certain probes/migrations unacceptable and simply not respond to them. That possibility isn't currently discussed in the text. The solution to both appears to be the same: Condition the MUST on acceptance of the migration. If the migration is somehow unacceptable (the remote address violates some deployment-specific rule, or the migration is prohibited by this version of QUIC) these requirements simply don't attach. The recipient doesn't change where they're sending packets or validate the new address. That might mean the connection fails rather than migrating, but that's the price you pay. I think this is editorial, because it acknowledges a carve-out in the MUST that we've always implicitly used to accommodate other text in the doc.
says: for future work. If a client receives packets from a new server address not indicated by the preferred_address transport parameter, the client SHOULD discard these packets. However, this is after several sections which describe how connection migration works generically from either side, including this text in 9.3. frame indicates that the peer has migrated to that address. In response to such a packet, an endpoint MUST start sending subsequent packets to the new peer address and MUST initiate path validation (Section 8.2) to verify the peer's ownership of the unvalidated address. Which is confusing and in fact arguably contradictory. I would propose that we add a sentence to the top of 9.3 that explains that while the text is generic, it actually only applies to servers.
Is this enough? This appears in (that's paragraph 6, not sub-section 6 in case you look at the URL).
It's not awesome because it basically contradicts the generic text in 9.3. But maybe we're past the point of diminishing returns
The intent was to keep the path validation mechanisms generic so that an extension could potentially introduce server migration later.

It's stated in 9.6 and the top of 9; before and after the generic part seems sufficient to me. That said, I think the server migration extension would still require that the client be the one to actually make the change. Only clients should ever spontaneously send from a new address. (P2P scenarios notwithstanding....)
NAME do I read your last comment as you being OK with closing this with no action?
To be honest, I still think this could use some work, but I'm willing to let it drop.
Thanks. Let's see if someone has energy/interest to do a PR during the next few days.
LGTM, but one nit. I'd like NAME to review this too.