....
or an added heuristic of "if have reassembled N datagrams for the same
source/dest/protocol tuple with ID's "larger" than 'this one' since it has
arrived, we are probably going to wrap so might as well drop 'this one'" for
some judicious and magical selection of N that may be a decent predictor of
wrap on top of some existing reassembly timout.
....

How do you define "larger" in this case? A sender is free to choose
any ID - they can't be assumed to be montonic, for sure.

Actually, I was ass-u-me-ing they would be monotonic, but thinking about it
more, that doesn't really matter. If N datagrams from that source/dest/prot
tuple have been reassembled since the first/current frag of this datagam has
arrived, chances are still good that the rest of the fragments of this datagram
are toast and any subsequent fragments with a matching src/dst/prot/id would
likely create a frankengram.

in broad handwaving terms, those N other datagrams (non-fragmented or fragmented
and successfully reassembled or not I suspect) are a measure of just how far
"out of order" the rest of the fragments of this datagram happen to be. for
some degree of "out of orderness" we can ass-u-me the datagram is toast.

chosing a strawman, if we've received 24000 datagrams from that source/dest/prot
(perhaps even just that source) since we've started reassembling this datagram
from that source/dest/prot, chances seem pretty good indeed that this datagram
is toast. a value of N even smaller than 24000 might suffice.