Whilst not quite the same, my solution has undergone some hefty structural changes over the years.
What I have always done is during any scripted import process, first import a single record / field from a table containing the version number of the file, then based on this information let the script decide which tables it should process etc.
Although it seems complicated, its fairly straight forward to maintain.
If I added a new table, I would simply wrap the import step like below
If [GetAsNumber($data_version) > 2]
Import Step here
End If 
Since my clients may upgrade at various stages, this approach worked best for me.
I've thought about doing something like this. Unfortunately, my data file doesn't contain a version number field. It should. My UI file does. I'll have to consider this more seriously now.
I'm pretty sure that, when the table defined in the script step as the source table doesn't exist (because the source is an older version of the solution), FM incorrectly picks the first table created in that file as the source.
Thank you for your post.
I am able to replicate the problem on Mac OS X 10.5.8, Mac OS X 10.6.4 and Windows XP.
One field from the original table must exist in the first table of the file for this to occur. Otherwise, you will receive the correct error message that the table/fields cannot be found.
I have forwarded your post along with my findings to our Development and Software Quality Assurance (Testing) departments for review and confirmation. Until this is changed, use the workaround provided by SWS (Thank you!).