Ok lets see. I think I've fixed the problem with retroactive purchases. It was hard coded to check order statuses with a status of 'completed'. It now set to check the configurable status set in the product feature setting page. The problem with leaving the download limit to null has been fixed as well. As far as the download number not changing, did you refresh the page after the download? After the file has transferred (i.e.. the 2nd last line of _file_download_transfer.) the # of downloads should be updated in the database.

To answer your question regarding the table associating files to users, this is done to store the relationship between users and files. For each user's file download there are a number of things we need to keep track of (IP addresses accessed from, downloads transferred, unique hash key, etc.). I'm sure there are ways to implement this relationship, but this is the one that seemed the most evident to me.

As far as the concerns with the large number of queries that the retroactive purchase can occur, that is something I haven't tested yet. Any large store built on ubercart is going to incur a lot of queries, probably with a lot of time outs as we encountered with our true equipment parts site. Just because of the sheer numbers, you can't get around that. I'd recommend either inserting the PHP set_time_limit function or perhaps coming up with programmatic solution for setting up downloads for previous product purchases.