In a normal or standard setup, Pro2 does not queue up the changes, it simply records that an "event" has happened on a record in the source database, storing database name, table name, rowid of the affected record and a few other event handling fields (date, time and status, etc.)
When Pro2 encounters an event that needs to be replicated, and that event was not a "delete", then Pro2 re-finds the current copy of the record, by db/table/rowid, and copies current values of all mapped fields to the target db.
If multiple updates to the same source record happen before Pro2 processes the event, then all of the changes to the record are copied when processing the first event. This happens due to the re-read of the source record and the copy to target is based on the "state" of the record at the time of that db read. When multiple updates to the same row have been queued, the other queue records also get processed, unless queue compression is enabled, but it's basically a resend of all the same data.