I think the simple solution to what your saying is basically do a sanity check on the test before it is added to the dropped test que.
The first thing to do would be create a dat list which only contains k/n pairs which require more testing.
The dat list would continually decrease in size by two criteria:
1. If a factor is found remove that k/n pair from the (dat/server que).
I know this happens, since when Joe and I submitted a large number for factors at one time. The number of tests in the second pass que reduced by the number of tests complete that day plus the number of factors we submitted. This was one of the ways we knew our secondpass sieve effort was actually working and those factors were actually previously missed.
2. If two matching residues are found remove that k/n pair from the (dat/server que).
I don't think this is happening, but it would slove almost all que issues if the following were done.
When a test is dropped perform a sanitiy check before are added to the dropped test que.
Does the k/n match one of the k/n in the dat list? No discard
The only issue would be an early double check, and a tripple check if the at fault/dropping computer ever finished the test. Also if someone were to invent a test it would never enter into the system (A common problem).