This description is taken from WT-13132:

However, it occurs to me that the code is reading the current metadata, not the state of the bitmap at the time the top-level backup cursor was opened. That works because the bitmap is always-additive. But it means if the top-level backup cursor is open a long time, later checkpoints continue to update the bitmaps. Therefore the incremental backup could be copying more data than was necessary at the time/checkpoint when the top-level cursor was opened.

Currently the first dup_cursor->next call reads the metadata configuration for that file via a single call to wt_metadata_search(session, btree->dhandle->name, &config). We would have to write a new function to get the metadata from the WiredTiger.backup file instead of the current live metadata.