Change:
migrates away from a local address SHOULD retire all connection IDs used on that address once it no longer plans to use that address. <del> An endpoint can cause its peer to retire connection IDs by sending a NEW_CONNECTION_ID frame with an increased Retire Prior To field. Upon receipt, the peer MUST first retire the corresponding connection IDs using RETIRE_CONNECTION_ID frames and then add the newly provided connection ID to the set of active connection IDs.  Failure to retire the connection IDs within approximately one PTO can cause packets to be delayed, lost, or cause the original endpoint to send a stateless reset in response to a connection ID it can no longer route correctly. An endpoint MAY discard a connection ID for which retirement has been requested once an interval of no less than 3 PTO has elapsed since an acknowledgement is received for the NEW_CONNECTION_ID frame requesting that retirement.  Until then, the endpoint SHOULD be prepared to receive packets that contain the connection ID that it has requested be retired.  Subsequent incoming packets using that connection ID could elicit a response with the corresponding stateless reset token. </del> <ins> An endpoint might need to stop accepting previously issued connection IDs in certain circumstances.  Such an endpoint can cause its peer to retire connection IDs by sending a NEW_CONNECTION_ID frame with an increased Retire Prior To field.  The endpoint SHOULD continue to accept the previously issued connection IDs until they are retired by the peer.  If the endpoint can no longer process the indicated connection IDs, it MAY close the connection. Upon receipt of an increased Retire Prior To field, the peer MUST stop using the corresponding connection IDs and retire them with RETIRE_CONNECTION_ID frames before adding the newly provided connection ID to the set of active connection IDs.  This ordering allows an endpoint that has already supplied its peer with as many connection IDs as allowed by the active_connection_id_limit transport parameter to replace those connection IDs with new ones as necessary. Failure to cease using the connection IDs when requested can result in connection failures, as the issuing endpoint might be unable to continue using the connection IDs with the active connection. </ins> 5.2.

Discussion:
Removes guidance on specific times in favor of descriptions of what the CID issuer might have to do if it can no longer support outstanding CIDs. I believe the impact of this is editorial, but I touched normative statements, so if anyone disagrees please scream.
Marking this as design to avoid accidental closure of the linked issue (which is design). Including this change in changelogs won't hurt either, though it is extremely minor.
NAME there are a couple of outstanding comments -- can you handle those and close this off?
Requiring RETIRECONNECTIONID has lead to all sorts of corner cases. For instance, a server can force a client to retire the connection ID that is still in use for the handshake. (We're uncertain yet as to whether the newly provided connection ID usable here, so this only might cause genuine problems.) More to the point, this design assumes things about the nature of connection IDs and routing infrastructure that imply a coupling between path and endpoint state. The reason you might want to retire a connection ID forcibly in this fashion is that it is no longer usable for routing purposes (or that it results in suboptimal routing, perhaps where packets need to be bounced between nodes in a cluster). All of this implies that the address tuple is part of the routing assessment. That makes this feature fragile and it also creates some uncertainty about whether it is possible to build such a system without having a stateless reset oracle.
Just to clarify, my understanding of the problem here isn't itself, but rather that an issuer of a CID can send to require that the consumer MUST retire the CID immediately?
NAME I'm not sure if I follow what you state here. Much like a TLS server having a master key that encrypts TLS session tickets, a server might have a master key that is used for encrypting all the CIDs, and it rotates that key periodically. In such a design (which I'd assume to be pretty normal), there is nothing related to paths.
MsQuic also uses CIDs and RetirePriorTo to encode "on machine" routing information, such as per-CPU partitioning. When we rebalance load across these partitions, we generate new CIDs to match. I also don't quite understand the point of this issue.

If the problem is just that we don't want CIDs to change before a certain time, I'm fine with adding some extra restrictions on that. But I'm very strongly against removing this feature (assuming that's the goal of this issue).
This isn't about being bound to addresses, though. It's about anything in the server infrastructure changing. That could be rotation of the keys used to encrypt a structure to produce packet IDs. I think there's a separate discussion about whether CIDs can be bound to server IPs for preferred addresses, but that's covered by already.
Discussed in ZRH. Proposed resolution is to prepare a PR that clarifies the consequences for both sides on what happens when an endpoint sends a NEWCONNECTIONID frame, and for the receiver for what it means if it doesn't retire. Also, remove PTO from text related to retirement.
Thanks for writing this up!