Exact duplicates are easy enough, even Windows' file explorer can catch them most of the time (due to exact same file size and last modified date).
On the other hand, if they aren't exactly the same, do you:
- Check the version numbers in manifest.xml? But some authors only modify the file name, and it is straight-up impossible to come up with a one-size-fits-all algorithm to extract the version number from a filename. You can probably throw an LLM at it but that's like robbing a bank with a tactical nuke.
- Check the size? But it is entirely possible for an updated mod to have a smaller size because of better compression or removing deprecated assets.
- Keep the one with more files? Same problem as checking for file size.
- Last modified for individual resources? This one's a bit more reliable, but how do you pick a representative date for the whole zipmod? What if the mod was hard-forked or personally tweaked to handle certain issues?
Checking these in serial can probably find an outdated mod with 90%+ accuracy, but it's always the last 10% that takes 90% of the actual work (specifically, human intervention to see which copy to keep). There is also the problem of the order to apply these checks in, as well as accounting for mod migrations and stuff, which is a whole other can of worms.
By the way, KKManger's "Tools > Cleanup duplicate zipmods" is (was?) completely unusable because it always prioritizes keeping Sideloader mods and will happily delete your copies in ~/MyMod even if they are certifiably newer. At least that was the case last time I checked the source on GitHub.