logging fixschemadifferences may lead to log tables with fields in a different order than the original table
I haven't looked yet to see if this is actually a problem, but I think the algorithm I used assumed the log tables would have the exact same order of fields. Putting this here as a placeholder to come back to.
Briefly, when there's an upgrade in core that adds a column, the log table gets sync'd but it adds the column to the end of the log table, after the log_xxx columns, not in the same spot as in the source table.