What would be the purpose of such a table?
One FileMaker File can import data directly from another so you don't have to export the data then import it. If you do decide to export then import, exporting merge files allows you to import with the matching names option.
What you describe has many potential pitfalls to deal with. Primary keys generated by serial numbers will not be unique and if data is separately modified by two different users, merging the changes back into a single record that contains the changes made by both is not a simple thing to accomplish.
I see your point re. unique fields.
However, if you have 2 standalone solutions, not filemaker server, with separate users on PCs linked over an intranet, would records be transferable then?
They are transferrable in any case, but the results may not be what you want as you might end up with a mix of records with duplicate values and possibly multiple copies of the same record from different sources--each edited so that they are not exactly the same and thus creating an issue on how to "merge" the changes made to each copy so that the most accurrate and up to date info is retained and the duplicates are removed.
These issues may be small an manageable or huge and very complex depending on the design and use of your stand alone database files.
The records would be selected based on name + some reference to date of birth and date of the calculation. So it should be possible to tell from the Calculation date, if there's been a modification, but yes, unchanged records could be duplicated.
While you can tell what records were modified, you won't know how they were modified.
Consider this hypothetical scenario that may or may not apply to your project:
User one takes their copy of the database with them on a lap top while they meet with clieint Jim Smith. Jim lets the user know that his office extension has changed and so User One modifies the contact record to replace the old phone number with the updated one. At the same time User Two accesses Jim's contact record and notes that the street name in the address field has been misspelled. He corrects the misspelling.
Now, if you perform an update type of import to merge your data back into a single set of data, the import will either lose the correction to the street name or it will lose the change to the office phone number depending on which set of records is imported into which. (And if goth users have their data imported into a central file, the change made by which ever user "synchs" their data last will be kept and whichever synchs first will have their changes for this same record lost.)
And with such an "Update matching" type import, records--whether changed or unchanged will not be duplicated.
It IS possible to track each change made to each field and then merge all changes on a field by field basis--I've worked out a method for that on paper--it's a far from simple process to track the changes and then merge them during such a synch operation.
Please note that SeedCode and 360Works both offer data synchronization tools that can be purchased and made part of your database solution. I do not know whether or not they address this particular issue.