> Unfortunately, MH believes that this is merely an a duplicate message or a
> corrupt message and ignores it.

Oh man, that's "interesting"

The response to a status request contains no message type identification.  As a result, MH can only identify a state request response if it knows that it just asked for one.  When MH receives one out of order, MH unfortunately has to just dump it because in a vacuum MH can't really determine what it is.  

MH actually dumps a lot of otherwise valid Insteon messages, because the Insteon spec is "stateful" in that the messages themselves do not contain the "state" information which would allow them to be received out of order. 
 
I'm a bit dismayed that mh got corruption from that device because it's dual
band, ....

I found it a little odd too. I do see that there is some activity occurring with this device (maybe you manually changed its state?) right around this error, but it looks like it occurs after the error so it is probably not the cause.  The corruption could also be happening on another device that is relaying the message.  I wish I had a better explanation for you.  

During a device sync, would it make sense to just blindly write everything
that should be, and then re-read the whole device's link table, ....

This would really slow things down, particularly if someone was adding a bunch of new devices at once.  As you note, this can be done, but would be complicated to enact.
 
> 3. Do nothing.  ....

That's a simpler and more reasonable IMO. ....

 Agreed, I think this is the way forward and is already entered as issue #73.
 
> The third run should not have resulted in anything happening, but I see it
> is "updating" a number of links added to gar_outlights_kpl.  ....

I think I saw an issue on that already, so no need to open a new one, right?

No need, an issue was created and closed as a solution has already been submitted. 
 
Say, if mh lost the state of the PLM, shouldn't it have a different value
for the version number on the insteon device's aldb?

Unfortunately, the PLM doesn't have an ALDB Version number.  At least not one that I am aware of.  As a result, it is always scanned no matter which option you select.