Currently the model stores the entities by uid.
When reducing on a query and the selection changes (e.g. a new thread leader), then we currently have to remove the old entity and add the new entity.
It should be possible to handle this better using a modification:

• Report that one entity replaces the other to the model
• don't use the hash of the uid directly in the model internals as in modelindex id (just keep a mapping to a random id), and thus allow to update that mapping.
• Turn remove + insert into a modification.

This is not of high priority as the impact is currently minimal.
Advantages could be:

• the visualization of a threadleader change in the maillistmodel would be better with a modification.
• the listview can maintain the selection.
• the conversation view could avoid completely reloading IF we always first query for the thread, and then only requery if the thread changed (currently we update as soon as the mail changes, which would still be the case). This optimization could also be implemented without the modification update, but the current selection breaks when the thread is removed and readded.