Last year I started the following thread:

http://thread.gmane.org/gmane.emacs.gnus.general/82121

In a nutshell: I was on vacation with a horrible mobile connection, and
nnimap kept doing those 'initial syncs', downloading hundreds of
kb. Nobody really knew what was going on, Lars only mentioned that it
was probably due to 'unexist' handling.

Since I'm doing my vacation at the same place this year, I just had to
debug this. Turns out it is indeed due to unexist handling using
QRESYNC. The problem seems to be this:

Say you have a group 'ding' and you refresh it on a QRESYNC-enabled
server. Gnus will look at the VANISHED answer and mark those articles as
'unexist'. However, if the group does not have any vanished articles,
the group's info will just contain '(unexist)' in its marks (hit 'G E'
to see it).

Now, when you enter this group and simply exit it again, you'll see that
this '(unexist)' range was deleted, which kinda makes sense because,
well, its an empty range, so why keep it? The problem is just that
nnimap-retrieve-group-data-early will now think this group was not
synced before and retrieve *all* flags instead of just the last 100,
which is what this 'doing initial sync' really means.

So the fix is pretty simple: Keep empty unexist ranges in the group's
info. The attached patch does that, but I'm not sure if this really is
the best solution, or if maybe this shouldn't be better fixed in
nnimap-retrieve-group-data-early?

-David