Well, calculation fields are not really "data" per se; they just manipulate real data to produce a result. So, you'd you need to do a separate Import from the related table.
Now how to do it efficiently, that's the rub (as they say). You would want to have a unique primary ID in the related table also.
You need to Show All Records (or at least relevant records) in the target file/table before using Import w Update matching.
It is possible to show the related records from the records of a "parent" table, by using Go To Related Record [ relationship; Show only related; Match records of found set; layout of child table ]. It can be slow, but works well.
[P.S. The current parent record must have a related child record, or nuthin' happens. Run from the "parent" table, a short script (section) can Loop until it finds one which has a related record, then Exit Loop If ; then the whole GTRR works.]
If you run such a routine, after doing the main "parent" table Import, then you can isolate their child records on either side, making (fairly) efficient matching for the child Import.
It is pretty unavoidable for one person's edits to overwrite anothers; latest wins (even if latest is blank).
FileMaker Server would solve this problem. Heck, even FileMaker Pro Sharing would solve this; let one (and only one) person/machine be the "server" computer and the other(s) clients. Requires some discipline, and can be a little problematic. But anything beats having to synchronize data; unless you simply must be offline separately.