I don't know about this specific case, but most of the time apparent anomalies in tables are reflecting taxonomic changes or issues. It is not uncommon for a taxon name to have a different meaning  depending on the context in which it is used.  In Recorder 6  this is normally reflected by a taxon name having a different meaning depending on the list on which it appears, but I suspect that the R3.3 list was in use for such a long time, that some taxon names  have ended up with two different meanings within the same list.   

There are a number of ways changes in the meaning of a name can occur. An example which occurs fairly frequently is where it is discovered that what was one species in fact contains two. One of which corresponds with the original description and type species and one which is different and therefore worthy of species status in its own right. The split resulting from this gives one species with exactly the same name as that  original and a new species with a new name. In Recorder the original name will have a different meaning depending on the situation in which it is used. For example on an older list (say R3.3) is used the original name it will in  effect be an aggregate of the two taxa which  appear on a newer list. Normally Recorder can correctly  reflects this , because there are different TLI keys depending on the list chosen, so the list chosen has an impact on what is meant by a name.  In this situation to get accurate reporting and for the Gateway (which only uses TV keys) to correctly relect the position  there should also be four  taxon version keys, one for the original name, one with the same taxon name as the original, but representing the taxa without the split out species, a third one for the new species and a fourth one for the aggregate of the two new species.   NameServer should map the original TV key to the aggregate TV key and not to the TV of the species with the same name. The problem I think is that these and other complex splits/renaming are difficult to identify or understand unless you follow a group closely. For this reason the NHM have not always been aware and sometimes  a name has only one TV key, when it should have more than one. The only way this sort of thing will be resolved is if those with an understanding of the taxonomy and its history, identify these problems and ask for them to be fixed. This still leaves the practical problem of deciding which TLI or TV key to use when processing data. With new data in Recorder it should  be safe to use the latest list,  but when importing or keying data from old records in theory some consideration needs to be given to the lists to be used.