Waren het er maar zoveel... 7 van de 10 lijkt me een reeelere schatting. Waarmee je dus twee keer 3 van de 10 overhoudt om uiteindelijk maar een gemergde basis van zo'n 50% te hebben

Magoed, een deel van de ongebruikte accounts kunnen we vast wel weggooien, dus dat ruimt dan weer wat op.
Ik heb geen idee hoe crisp's omzetscript in elkaar zit,
Crisp mocht willen dat ie die prachtcode had geschreven!

maar ik kan me voorstellen dat dat script onder andere kijkt naar overeenkomt in zowel username als IP,
Nee, dat werkt niet. Het enige waarvan we echt zeker weten dat het dezelfde persoon is (niet voor niets ook de identifier die er uberhaupt een persoonsgegevens van maakt) is het mailadres.
Waarbij we overigens niet naar het registratie-adres kijken, maar naar het gewone gebruikte. Dat zou eventueel nog aangevuld kunnen worden, maar de "algoritmes" moeten we nog een beetje fine-tunen.
Natuurlijk zul je in dat geval altijd users hebben die niet gemerged worden, of die gemerged worden met een account van iemand anders, maar dat is waarschijnlijk achteraf wel te fixen.

Dat lijkt mij, eerlijk gezegd, juist het meest ongewenste bij-effect dat er uberhaupt mogelijk is... Want het is
niet zo makkelijk te fixen achteraf, dat zou betekenen dat je een nieuwe user moet maken en uit moet zoeken welke berichten onterecht aan de ene gekoppeld zijn om ze dan daarna aan de nieuwe te koppelen... rotwerk en onnodig bezwarend voor de slachtoffers (want die worden effectief volledig verwijdert dan!), doen we dus niet.

We gaan alleen mergen als we met redelijke zekerheid kunnen stellen dat iemand inderdaad dezelfde op GoT als T.net is, oftewel hetzelfde mailadres hebben. Of liever nog natuurlijk door hem dat via de merge-voorkeuren in te laten stellen.
Achteraf nog meer merges doorvoeren is aanzienlijk makkelijker dan achteraf ongeldige merges verwijderen. En dat laatste wil ik nog wel overwegen om te doen, dan kunnen we het ook tijdelijk doen voor het samenvoegen van allerlei kloontjes e.d..