This is an alternate and improved method to support CONDSTORE and QRESYNC compared to my original attached diff. With my original approach, mostly based on the current CONDSTORE implementation, reliably detecting message flag changes, additions and removals (expunges) by other clients when only CONDSTORE was in effect, without doing a full flag fetch, was often problematic. (The primary reason for supporting CONDSTORE and QRESYNC is to reduce the occurrence of full flag fetches [syncs] so a mailboxes with thousands of messages requires a shorter wait for sync to complete on the initial select.)
The issues with my original diff were more pronounced when the server only supported CONDSTORE, such as gmail. (Edit 8/11/23: The main issue is when a message is deleted by other client or another TB instance, this TB instance must be restarted for the message count to go down and for the message to disappear from the list.) This diff now builds a "backfill" array of UIDs, indexed by message sequence so that the effect of a message expunge is immediate. The backfill array is created from the UIDs already stored in the database on the first folder select during a session. But it can only be created this way when nothing was expunged by another client while the the folder was not selected or when tb was shutdown. Otherwise, if something was expunged, the array is not created by backfill but is created from scratch by a full flag fetch in the original way.
Edit 8/11/23: The backfill still does not eliminate the the need for full flag sync such as when the other client/TB instance deletes a message with this TB instance shutdown. QRESYNC is require to handle this but gmail still does not support QRESYNC. (From what I can tell, gmail is the only server type that supports CONDSTORE but not QRESYNC.)
The implementation of QRESYNC (supported by many popular non-gmail servers) is mostly the same as the original diff and, theoretically, should require only one full flag fetch (if there are no bugs in the server and the client).
This is a large and complicated change (I've been working on it since September) and requires a lot of detailed and often tedious testing to ensure everything is working as expected with the various imap server types, using multiple clients or tb instances while recording and examining the corresponding imap logs. I've done a lot of testing and code fixing but I'm sure more would be needed.
Since, as I was just recently informed, the c++ code this is based on is scheduled for complete replacement, I'm not submitting this as a formal patch for review. Hopefully, it might be useful to someone in the future. I had intended to write a updated detail "theory of operation" like this but since it's probably doubtful that this patch would ever be used in its current form, I'll let the code and comments (in the diff) be the documentation.