ok, i did misread the spec in a subtle way. the thing is that while all
other folders are physically nested under INBOX, the imap view puts them
at the same (root) level. to get them shown as subfolders of INBOX, they
need to have _two_ leading dots, as we've seen in the example with
evolution (though i don't see that actually specified anywhere -
somebody cares to verify with dovecot and courier?). this is rather
counterintuitive.
the consequence is that i need to a) adjust the name mapping algorithms
and b) forbid setting Path when SubFolders is set to Maildir++, as in
this mode the location of all boxes is determined by Inbox as i've said
before.
i'm not entirely sure what to do with the Verbatim mode. in principle,
it's possible to use it to work with dovecot's maildir++ with the "fs"
layout by setting Inbox and Path to the exact same location. the caveat
being that physical subfolders of Inbox must be ignored for INBOX'
purposes - they may show up only relative to Path (i.e., as top-level
folders). this is exactly opposite to the case where somebody chooses to
put Inbox under Path, in which case subfolders of Inbox most definitely
*should* show up under INBOX, as they couldn't be sensibly represented
relative to Path ("<inbox's-real-name>/subbox" makes semantically no
sense).
