So, the way it handles the resume of a possibly changed file is by comparing filesizes. This is the info it stores in the registry. For me, this was enough, since the files I'm downloading are 4MB+, and thus any changes to the build large enough to make it to production are most likely going to change the filesize. However, I can see that if you were using NSISDL to fetch, say, an ini file, it may very well be the same size and a different version. So, adding something based around the "Last-Modified" header would solve that problem. At the time, writing something to parse HTTP-date fields was more than I felt I could pull off in a couple hours.
In any case, as it stands, if the size reported by the server differs from that in the registry, it starts the download over again. This should also take care of any non-HTTP1.1 servers, since it will report the full size of the download, which, added to the size already downloaded, would be incorrect, triggering a re-download. Which is all you can really expect from a server that doesn't support resume. That's not really perfect, either, since it is possible that the server filesize would have changed to exactly the right size to match up with the old filesize minus the current amount downloaded, but that would be fixed by the above timestamping.
As far as the registry goes, it can certainly be improved by deleting the reg value after a successful download, and removing the NSISDL key if there are no more subvalues. It would still be possible that a key would left behind if a user never finished his or her download, and I can't really think of a way around that. The "metadata" about the partially downloaded file needs to live somewhere.