Sometimes evolution gets confused when it makes some changes on one connection and receive them back on another IDEL connection, as races can happen in how things are applied.

Some details have already been provided to the maintainer directly, but I am available for further inquiries.

This is part of the explanation about the issue as exchanged via email:

> There are active three
> connections, A, C, and D. The C does the update of some other folder
> and clutter the log with a boring stuff. Connection D is used for the
> deletion, there was run the STORE of the \Deleted flag and the expunge.
> Finally the connection A is in IDLE on the same folder as the D, which
> is Lists/sssd-devel. The thins is that the A, while in IDLE, receives
> also flag changes in that folder, but not based on the UID, but based
> on the index number in the folder summary (that's how the server
> reports it).
> 
> The run is this:
> A - parses received flag changes in the folder
> C - stops IDLE and runs the flag receive in some other folder
> D - runs store on the \Deleted flag on the 4 messages
>   - while the A is still processing previously received data,
>     the D calls EXPUNGE and received confirmation immediatelly
>   - ignores EXPUNGE responses, because it run the EXPUNGE command
>   - two out of the 4 deleted messages are removed from the local
>     summary at the end of the EXPUNGE command of the connection D
> A - is still parsing old stuff
> D - goes into IDLE
> A - only now received the \Deleted flag changes being done at the
>     beginning in the connection D - that's too late, there are already
>     removed messages in the local summary, and the flags are received
>     with their sequence number, not with the UID
>   - sets the \Deleted flag on the 4 messages
>   - receives EXPUNGE notifications, but ignores them
> C - still receiving stored flags on the messages in the other folder