Completed.  Added advanced preference that allows non-IMP managed 
keywords to be displayed to the user.

Also (not directly related to this ticket), changed out keyword naming 
system to allow use of the keywords in other MUAs (by using the label, 
after stripping out disallowed characters).

Changes have been made in Git for this ticket:

Add preference to show flags created by other MUAs (Request #8882)

http://git.horde.org/diff.php/imp/config/prefs.php.dist?rt=horde-git&r1=0f573fda077bc7596c65b6ea2a09ad97b5eb7ef3&r2=a1d3bb1a9c45b10fb08c741b075aa02da2c8e561
http://git.horde.org/diff.php/imp/docs/CHANGES?rt=horde-git&r1=fda1bfe7f1abcc401dfe96ada639c15b74765ea8&r2=a1d3bb1a9c45b10fb08c741b075aa02da2c8e561
http://git.horde.org/diff.php/imp/lib/Imap/Flags.php?rt=horde-git&r1=c4a8bbfa852ae49c87acf4806c51b8c241af2f12&r2=a1d3bb1a9c45b10fb08c741b075aa02da2c8e561
http://git.horde.org/diff.php/imp/templates/prefs/flags.html?rt=horde-git&r1=43ee04f2b17f507dd6dda3586eea9b108ba6f2c2&r2=a1d3bb1a9c45b10fb08c741b075aa02da2c8e561

Maybe we should instead implement this like Thunderbird. I guess the 
label syntax is limited anyway? How about non-ascii chars or spaces? 
If those are not possible we should consider using generic labels too 
and store a local map in the prefs.

I'm assuming you would be requesting a preference for this behavior, 
turned off by default?
Unfortunately, this isn't always the case.  Putting '$' in front of a 
flag is a convention, but not a requirement.

On one hand that's a pity, because those flags aren't very portable 
then, otoh it makes perfectly sense for Thunderbird of course, so you 
don't have to care about charsets and special chars in labels.
I still think this might be useful for few people. Custom flags are 
only used by power users anyway and my guess is that those are happier 
with seing generic label names than no labels at all.
The approach of collecting all flags and let the users decide which 
ones they want might be the better the solution, but it's also more 
work to implement.
Those are the (to be excluded) $ flags anyway.

Changes have been made in Git for this ticket:

Bug #8882: Add blurb about default non-settable flags

http://git.horde.org/diff.php/imp/docs/UPGRADING?rt=horde-git&r1=9ad763efa473b2301c7280cc0d6d8ed8eae2fe24&r2=1150d556a351467cef2b1ef4fa7d8d561661e5a8

Changes have been made in Git for this ticket:

Bug #8882: Don't allow flagging deleted by default

http://git.horde.org/diff.php/imp/config/prefs.php.dist?rt=horde-git&r1=bcd4f69f6d59f3404c3befe5cc0ccf947b946eab&r2=0d526b27581921cee7fe8d8571638ccfa0b9f5e2

e.g. I'm pretty sure T-bird uses "Label1", "Label2", etc. as their 
custom message flags.  So I still fail to see how displaying the IMAP 
keyword nameis useful (since the mappings between "Label1"  (the IMAP 
keyword)-> meaningful label resides in the MUA's preferences, not the 
IMAP server).

If "Label1" may mean TODO in T-bird, but will appear as "Label1" in IMP.

AFAIK, only 4 other keywords outside of RFC 3501 have "official" RFC 
designation.  See 
http://tools.ietf.org/html/draft-melnikov-imap-keywords-10

Though this was with the fresh preference value from prefs.php.
True, but it would be a great bonus if the MUAs would share their 
flags. I think it's probably safe to use anything not starting with $ 
or \\ to be a user flag that should be included.
That sounds overly complicated to me. I'd rather try to add the flags 
automatically where we see them, i.e. when opening a mailbox with yet 
unknown flags. Then see how this works in real life.
My guess is that most users will be suprised (in a good way) to see 
their flags popping up automatically.

Sure.  Although the default is not to allow the deleted flag to be set 
so this is probably why I haven't noticed this.
I have thought about this previously, but I'm not sure it's the best 
idea.  We have no way of knowing what non-standard RFC flags mean.   
Mappings for these non-RFC flags -> labels is MUA-specific.

I could see us adding an advanced option in the flag preference screen 
that would scan all mailboxes for available flags, present them to the 
user, and allow to set specific labels for any flags the user 
recognizes.

Indeed. I had the \\seen and \\deleted flags with type "imap" stored 
in the prefs. Probably from an earlier incorrect version of prefs.php. 
After removing the old pref value, the flags (almost) appear correctly 
now.
Two other issues that I'm noticing now though:
- Shouldn't the \\deleted flag entry be hidden automatically when 
using the trash folder?
- Shouldn't the custom flags that are stored in the mailbox and 
returned by the SELECT call be automatically added to the msgflags 
pref, or at least added to flag list on-the-fly?

Verified that, until 5 minutes ago, dimp was disregarding available 
PERMFLAGS for a mailbox.  So the only explanation for the behavior you 
are seeing - at least that I can come up with - is that your prefs 
configuration is blocking the display of the seen flag.

Re-reading this - by default, you shouldn't have the Draft flag 
available either.  The only way draft could be available is if you 
have modified the 'msgflags' prefs.php value (flags with 'imapu' as 
the type are the only flags settable to the user).

For now, looks like we aren't using PERMFLAGS return in dimp.  Should 
probably fix this.

I only see an EXAMINE if that's what you mean:

S (1267030529,5944): * OK [CAPABILITY IMAP4 IMAP4rev1 LITERAL+ ID 
STARTTLS AUTH=PLAIN SASL-IR] neo Cyrus IMAP4 v2.3.11 server ready
C (1267030529,595): [SASL-IR AUTHENTICATE Command - username: jan]
S (1267030529,7251): 1 OK [CAPABILITY IMAP4 IMAP4rev1 LITERAL+ ID 
LOGINDISABLED ACL RIGHTS=kxte QUOTA MAILBOX-REFERRALS NAMESPACE 
UIDPLUS NO_ATOMIC_RENAME UNSELECT CHILDREN MULTIAPPEND BINARY SORT 
SORT=MODSEQ THREAD=ORDEREDSUBJECT THREAD=REFERENCES ANNOTATEMORE 
CATENATE CONDSTORE IDLE X-NETSCAPE URLAUTH] Success (no protection)
C (1267030529,7268): 2 EXAMINE "INBOX"
S (1267030529,7275): * FLAGS (\Answered \Flagged \Draft \Deleted \Seen 
NonJunk $Label2 $Label1 $Label3 $Label4 $Label5 Junk $Forwarded 
NotJunk foo AMMMa Consulting $NotJunk JunkRecorded $Junk Training 
$MDNSent KMAILFORWARDED KMAILTODO KMAILWATCHED KMAILIGNORED $TODO 
$WATCHED $IGNORED)
S (1267030529,7289): * OK [PERMANENTFLAGS ()]
S (1267030529,7292): * 104 EXISTS
S (1267030529,7294): * 0 RECENT
S (1267030529,7296): * OK [UNSEEN 92]
S (1267030529,7298): * OK [UIDVALIDITY 968256253]
S (1267030529,7299): * OK [UIDNEXT 211934]
S (1267030529,73): * OK [NOMODSEQ] Sorry, modsequences have not been 
enabled on this mailbox
S (1267030529,7302): * OK [URLMECH INTERNAL]
S (1267030529,7303): 2 OK [READ-ONLY] Completed
C (1267030529,7574): 3 LOGOUT
S (1267030529,7583): * BYE LOGOUT received
S (1267030529,7586): 3 OK Completed

Check your IMAP logs - specifically the PERMANENTFLAGS response from a 
SELECT command - and post it here.  I am guessing that this mailbox 
does not allow the Seen flag to be changed.

The removal should be mentioned in CHANGES then.

Not for me. I only have Draft, Flagged, and a custom flag in the flag menus.

Unseen: that's the first option in the flag menus (?)
Answered: that is by design.  A reading of various RFCs indicate that 
the Answered flag is equal to 'replied-to'.  It should not be user 
settable (it is similar to the $Forwarded flag).

Same for (un)seen.

.