What state are we speaking about? I think that we are saying either too much or too little. There many kinds of "states":

1. Lists of packets that were sent on the path and not yet acked by the peer,
2. Packets that were received from the peer and processed but not yet acked,
3. the total number of paths considered active, which some implementation use to decide when to increase the Max Path ID.

Suppose that an implementation has abandoned a path, had not received a Path Abandon from the peer, and is losing patience. It may do a number of things:

1. It may decide to drop any incoming packet on that path. That has no interoperability impact, as long as those dropped packets are never acknowledged. Indeed, that's exactly what would happen if the path had become bad and packets were dropped in the network. But it has some performance impact, since some packets will be in transit when the Path Abandon is sent. It is recommended to not do that earlier than 3 PTOs after sending the PATH_ABANDON frame.

2. It may decide to consider all packets send on that path as lost, and resend the frames through another path. That's fine. It might cause some duplicate transmission, but that also happens for other reasons (e.g., bad timers) and has no interoperability impact. The rules there are murky, because this is a tradeoff -- resend sooner minimizes the end-to-end latency caused by losses, but resend sooner also increases the risk of duplicate transmission, which reduces efficiency. The 3PTO rule is probably one end of the tradeoff: good mitigation of duplicate transmission, poor management of latency. A 1PTO rule would be a different tradeoff, more focused on managing latency.

3. It should send the "missing ACKs" on another path before clearing the missing ACK state. Again, that's an efficiency tradeoff. If the node does not send acknowledgements, it risks causing spurious retransmission.

4. It may well decide to never increase the MAX_PATH_ID until the PATH_ABANDON has been received. That's a reasonable way for an implementation to conserve resource.

I would just say:

If a peer sends a PATH_ABANDON frame but never receives
a corresponding PATH_ABANDON frame, it might not be able to remove path state.
It is left to the implementation to handle this unexpected
behavior.

What state are we speaking about? I think that we are saying either too much or too little. There many kinds of "states":

1. Lists of packets that were sent on the path and not yet acked by the peer,
2. Packets that were received from the peer and processed but not yet acked,
3. the total number of paths considered active, which some implementation use to decide when to increase the Max Path ID.

Packet handling as mentioned in point 1 and 2 seems actually partly orthogonal here. If you have send the path abandon frame, you should probably not have any outstanding packets that need to be acked on that path. However, you should also never just forgot about outstanting/non-acked packets. If you decide to remove state about non-ack packets, you need to declare them lost and resent on another path. I guess if you really want to sent a path abandon frame even though you have outstanding packets, you should probably declare them lost and resent on another path right away.

About your point 2, I don't think there is an issue here and I'm not sure when this case could/would happen. If you have received packets, I guess you should first send the ACK and then the path abandon. Of course you can also send ACKs on other paths still.

The important part is about packet handling of new incoming packets and you should be able to process those for at least 3 PTOs after sending the path abandon frame. This means, you need to remember the path ID and corresponding CID(s) as well as the packet number space state. However, as soon as you remove the CID(s), you cannot process any new incoming packets anymore and as such you can then also remove all packet number space state as well for received packets. For out-going packets, it's really on you if you remove state even though there are ACKs missing; however, as I said above that means you have to retransmit on another paths.

The interesting case is actually your point 3. If you remove path state that means you remove the path ID and will consider it as not active anymore. As such you could send a new max path ID. However, as the other end is not sending you a path abandon frame it will consider the path ID as active and not increase its max path ID. Respectively, you might not be able to open a new path. But I guess that's what we have the path blocked frame for. So I guess there is no problem either way.

So should we maybe say this to be more clear:

However, an endpoint SHOULD process incoming packets for the abandoned Path ID and corresponding connection IDs for at least 3 PTOs after sending the PATh_ABANDON frame.