I've uploaded version 2.1.5 with the following changes:
- InnoExtract is now supported on some Macs, thanks to chief1983 providing a Mac build of InnoExtract
- get the user.home path in a way that works on all platforms (bypass a Java bug that occasionally had user.home return the wrong location on Windows)
- properly exit a download if an error was encountered in the compression, as opposed to reporting success
- minor optimization improvements
Here it is! 
Thanks very much. I didn't see anything that looked like a smoking gun, unfortunately, although there were a large number of runs logged.
What I'd like you to do is delete (or archive) your entire logs folder, so that the 2.1.5 build starts with a clean slate. Then edit fsoinstaller.properties to remove the version numbers of the mods that were not downloaded. Then run 2.1.5 and see if the latest changes fixed your bug. If not, upload the logs folder again.
Furthermore, selecting "re-run installation for installed mods" seems to attempt to redownload all the things, whilst CRC-checking the actual files first and then re-downloading if the CRC check turns out to be a bodge would be a far more effecient solution.
This is actually precisely what is doing. It is re-checking each file in lieu of referring to its internal cache of mods that are downloaded vs. not downloaded.
Hmm. It seems to be drawing internet whilst the installer shows nothing being downloaded during this process.
Yes, it is accessing the remotely hosted zip file to compare its size with the size of the file that's locally on disk. This requires internet access even though nothing is being extracted.
The installer only knows about the archive, not the VP files contained in the archive. It doesn't actually scan the VP files until it attempts to download the mod, as mentioned in the previous point. If the installer scanned every VP file before displaying the list, there would be an unacceptably long delay.
Even if it automatically asumes that every file in there has been correctly downloaded, and merely checks for existence?
Yes, even then, because the delay is not on the local file system side. The delay is in getting the VP information from the archive file's table of contents over HTTP.