Comment 5 for bug 603402

I could see similar phenomenon with Tb 3.0.3, with Gmail IMAP, using single IMAP client(Tb), during test for Bug 450246(tag case) and bug 544439(\Seen flag case).

1. A mail has Gmail Label of [Gmail]/All Mail, Inbox, X/A1, X/A2, X/A3, ...
   "Read status" at all folder
2. Change mail in X/A1 to Unread
   => mail in some folders was changed to Unread. (not opened yet?)
   => mail in Inbox was not changed to Unread.
   => mail in other foldrs was not changed to Unread. (already opened?)
"Work Offline, go back to Work Online, Click the folder" was required to reflect status change.
So, it looked for me next phenomenon.
  If IMAP folder is already opened, re-synchronization of flag is not executed.

Dave Carner(bug opener) and Umang:

Can you get IMAP log and check IMAP level flow?
> https://wiki.mozilla.org/MailNews:Logging
> http://www.mozilla.org/projects/nspr/reference/html/prlog.html#25328
> SET NSPR_LOG_MODULES=timestamp,imap:5 (MS Win example)

Does Gmail IMAP return new status("no \Seen flag" status or "\Seen flag" status) after status change by other for the mail?
Does Tb know "change from with \Seen flag to without \Seen flag or vice versa" of the mail in Gmail IMAP folder?
Or Tb knows it but status of MsgDB/thread pane is not refreshed?

> and immediately go to All Mail, TB checks for new mails and marks ONLY the last three as read,

Tb knows highest UID(N) which is used and next UID(N+1) for new mail. Upon new mail check, Tb probably issues "uid (N+1):* flags". If no new mail with UID grater than N, Gmail returns flag status for uid=N. If new mails for Tb exist, Tb can obtain flag status for UID from (N+1) to (N+x). I guess you are looking phenomenon at this stage.
For old mail(UID M, M is less than N), flag status change(\Seen<->No \Seen) can't be obtained unless "uid M fetch flags ..." is issue again. I guess "status of old mail is not changed" is problem around this(phenomenon I saw).