The duplicate .table files from what I can tell come from using different database connection strings. I haven't looked for the code but I do know if I change the database type, user name etc in the DAL() connection string parameter it appears to generate a hash code from the string and prefix that onto the table name and then .table as the extension.
If you were to look in your development environment I am guessing one of the prefixes in your production set matches and if the production db connection string is different I am reasonably sure it will be using the other set of .table files. Except for SQLite I have found it only makes sense to preserve the database directory across installation instances if you use the exact same database connection string in both installations. Then I copy the database across using the database specific dump restore. If I get the tables already created error because I changed something I drop the database, clear out the databases directory, create an empty database, run the application up once to create an empty table and relations set and then load the data using the import from cvs file method. Now that I know what fake_migrate does I might try that next time by just deleting the .table files. My db is small containing configuration data for the application mostly so it isn't much of a hardship to toss these around. When the db is large it is a totally different matter that requires a lot more effort and time.
