I entirely disagree.  For the reasons I mentioned below (and then 
decided to ignore when implementing) - the principle of least surprise.

One example: I am viewing a message.  I want to set two flags on the 
message: unseen (i.e. unset seen) and TODO.  The issue is that the 
order of setting those flags matters(!)  I can set TODO and then unset 
seen and it is fine.  However, if you unset seen it is not longer 
possible to set TODO because the message is deselected.

*No* other flag does this. I can set/unset all the other 15 flags 
available to me and this won't occur.  I can even *unset* the same 
flag - seen - and nothing happens.  And there is nothing in the UI 
that would clue you to this fact - unsetting seen appears the same as 
every other flag action.

I actually found this very intuitive. You have a message selected so 
that it is displayed in the preview pane. You mark it as unseen, and 
the message *is* unseen by deselecting it and removing it from the 
preview. Couldn't be a more clear unseen action behavior IMO.

Changes have been made in Git (master):

commit d5750ed7bfe7435ec2b78a2a120dd77b52512b04
Author: Michael M Slusarz <slusarz@horde.org>
Date:   Wed May 14 01:02:02 2014 -0600

     Bug #12570: Don't set seen flag when switching to previously open 
message in a mailbox

  imp/js/dimpbase.js |   26 ++++++++++++++++++--------
  imp/js/viewport.js |    5 +++++
  2 files changed, 23 insertions(+), 8 deletions(-)

http://github.com/horde/horde/commit/d5750ed7bfe7435ec2b78a2a120dd77b52512b04

Changes have been made in Git (master):

commit eb32fe8aeb298fe03f433f0e00c6ad1d2a5eda7e
Author: Michael M Slusarz <slusarz@horde.org>
Date:   Wed May 14 00:52:02 2014 -0600

     Revert "Bug #12570: Unselect message when marking as unseen"

     This reverts commit 4159549cbbb2cb37e3190879bf8e3a62a027af0a.

     Conflicts:
             imp/lib/Ajax/Queue.php

  imp/js/dimpbase.js         |    4 ----
  imp/lib/Ajax/Queue.php     |   13 -------------
  imp/lib/Flag/Base.php      |   12 ------------
  imp/lib/Flag/Imap/Seen.php |    7 -------
  4 files changed, 0 insertions(+), 36 deletions(-)

http://github.com/horde/horde/commit/eb32fe8aeb298fe03f433f0e00c6ad1d2a5eda7e

Revisiting this.  This behavior, as implemented, is completely 
unintuitive.  I selected all messages in a mailbox, unset the seen 
flag, and the selection disappeared.  Completely not what I expected 
... and I'm the one that wrote this change.

It does appear that we will have to instead implement what I 
originally didn't want to ... special behavior.  But now that I've 
seen/used the alternative, it is the better choice.

Changes have been made in Git (master):

commit 4159549cbbb2cb37e3190879bf8e3a62a027af0a
Author: Michael M Slusarz <slusarz@horde.org>
Date:   Fri Sep 27 01:42:00 2013 -0600

     Bug #12570: Unselect message when marking as unseen

  imp/js/dimpbase.js         |    4 ++++
  imp/lib/Ajax/Queue.php     |   13 +++++++++++++
  imp/lib/Flag/Base.php      |   12 ++++++++++++
  imp/lib/Flag/Imap/Seen.php |    7 +++++++
  4 files changed, 36 insertions(+), 0 deletions(-)

http://git.horde.org/horde-git/-/commit/4159549cbbb2cb37e3190879bf8e3a62a027af0a

IMP 6.2.

That's exactly what I suggested in the original post.

But I still disagree because it is not consistent.  EVERY other time a 
message is selected it remains selected when returning to the mailbox. 
  We can't make this a special case based on the presence of a single 
flag.

I would think the correct behavior would instead be to unselect the 
message immediately when removing the seen flag.  Flagging messages 
MAY cause other actions to occur (e.g. flagging as deleted may move 
the message to the Trash mailbox), so this is more acceptable behavior.

We have the same problem with shared folders and shared flags.
Mark one message a unseen (because it is for a other person) and come 
back later to the folder mark it as seen again.

If i forget to mark it as unseen again the other users do not check 
the mail again, because its seen and in work...

+1

I agree that the least surprising behavior is a good guiding 
principal. That's exactly why I suggested this change. What might be a 
user's most probable intention when marking a message as unseen? 
Having it unseen. Having to unselect the message or doing some other 
actions to keep this explicit decision, just because the client has 
some side-effects while implementing the mailbox-state-restore is not 
very intuitive OTOH.

At worst, this is an enhancement request.  The current behavior is 
correct.  And I'm not sure I agree with you - to me, the principle of 
least surprise would require that we treat this action the same as any 
other action.  Namely - leaving a mailbox and returning always should 
reopen the previous message.

FWIW, our current behavior matches Thunderbird's behavior.

I could have sworn this had been fixed in the past already, but I 
cannot find the ticket. If marking a message as unseen in a folder 
(and thus selecting this message), and then going to another folder, 
coming back to the original folder marks this message seen again, 
because it is still selected. This is technically correct, but 
probably not what the user intended. I suggest deselecting messages 
after marking them as unseen.