Dave, to the best of my understanding, if you updated a record (and for the sake of argument, did so in a way that made a string field longer by 1 or more bytes), then this is what would happen.
JET/ACE would make a new, free-standing record that is not yet part of any table, then would copy fields one at a time in fielddef order, probably applying the update to the string field this record in passing. It would put this record at the first free spot in its current virtual memory area.
Next, it would perform a transaction style operation where both of the next two steps make it or neither makes it.
Thread the new, updated record at the end of the list of records that are in the table
Unthread the old record and close up any opened links needed to rejoin the records that had preceded or followed the now removed record.
At this point, you see the same number of records you started with but they are in a different internal order with the updated record apparently at the end of the list of table records. There is now an unthreaded record "floating" in the memory that was formerly part of the table, contributing to bloat until such time as the next Compact & Repair does its thing.
Is that what you were asking with your question?
As food for thought, considering corruption issues, if you have a power glitch between the point where you were unthreading the old record and rethreading logically adjacent records, this is when a table gets corrupted, because the links between some of its members are now broken.