This sounds like a bug that a few others have reported previously. I think the issue may be the fundamental design choice that SKIP_EXISTING requires both a filename and directory database match to trigger the skip. This was how the skip was designed when I took over the project, and I have done my best to only change functionality details where necessary (to minimize deviation). I thought that SKIP_PREVIOUSLY_DOWNLOADED (the global database) would catch edge-cases where filename is different but song_ids are the same. On further thought, you may be right about removing the filename requirement for local database match skips. I'll play around with that change and see if there was a good reason it was implemented that way originally.

EDIT: See if 4cc7e18 fixes the redownloads you were seeing before.

As far as using song metadata to check for duplicates, I am fairly sure that is not the direction that I want to go. Metadata can be (and often is) changed over the lifetime of a track on the API side. Theoretically, song_ids are the one thing that should not change, which is the reason a local record of them was chosen to maintain "identity". Additionally, many users (myself included) may make manual changes to metadata to fit personal stylistic/organizational formats.
TL;DR: metadata isn't enough to confirm a track's identity in my opinion. Willing to discuss this further though.