This has been brought to my attention while I was working on the master code for Tremulous attempting to get compatibility with IPv6: if a server sends heartbeats on both IPv4 and IPv6 addresses, there doesn't seem to be any way of checking that these are in fact both the same server, and hence the client is more or less obliged to list it twice.

An idea I discussed on the IRC channel the other day was the addition of a sv_guid to be sent in infoResponses: if two servers have the same GUID, list them once, perhaps with some indication of the multiple available interfaces. The problem with this becomes more or less immediately obvious when you consider the potential for abuse, where a griefer can take a server's GUID and copy it in their own infoResponses and hence the client is faced with the difficult problem of choosing which to display (or both). There was an idea to hash the GUID with the client or server's IP, but both of these suggestions destroy the original benefit of the commonality across IPv4/IPv6. People have even suggested some kind of asymmetric encryption method, with the drawbacks of requiring the exchange of at least 4 packets of larger-than-usual size, and the difficulty of finding an implementation of the relevant algorithms that doesn't require extra build dependencies or huge source files.
Other ideas are only sending the GUID to the master, which then has some way of deciding which address to send to the client, or some method of indicating that one server has two addresses. This poses a security problem but sounds a reasonable solution so long as it can be done without breaking protocol compatibility. Or a server could put all its addresses into its infoResponse, and they could then be merged only be mutual agreement (which suffers a little from the complexity of resolving grouped servers and the extra response string spam).