At the moment, quicly_receive has something like:
if (path_index != 0 && conn->paths[path_index]->path_challenge.send_at == INT64_MAX &&
!conn->paths[path_index]->probe_only) {
if ((ret = promote_path(conn, path_index)) != 0)
goto Exit;
recalc_send_probe_at(conn);
}
but RFC 9000 section 9.3 states:
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.
In case of quicly, the old path is deleted the moment path promotion happens. So if there is a reorder, quicly will try to probe the original path.