I've made some notes about the various flavours of folder names in use. I think a lot of the bugs we've got can be solved by being really clear on what the naming requirements are in each case, and how the various naming schemes should be mapped to one another.

Places where folder names are used:

Folder Name

• The 'canonical'/internal name of the folder.
• exposed via the nsIMsgFolder name attribute
• Usually the same as the user-facing name (but there is a prettyName attr too)
• Used to derive URI in nsIMsgFolder getURI() implementations.
• There is some special-case handling for certain folder names - case tweaking, localisation etc. See nsMsgDBFolder::SetPrettyName() for an example.
• There is also abbrieviatedName, which uses account-specific rules to shorten long names for nicer display. I think only Newsfolders use it (eg "comp.sys.lang.basic" => "c.s.l.basic").

User-facing names

• As displayed in the folder tree UI panel.
• Should probably be able to display any printable characters: non-latin chars, '/','' etc.
• TODO: look in the UI code to see where display name is taken from.

MailStore (ie mbox/maildir on filesystem)

• The names of files and directories on disk.
• Allowed characters depends on OS
• Case-sensitivity depends on OS
• some names illegal on some OSes (eg CON, PRN, AUX etc on windows)
• Some names have special significance? "INBOX", "Trash" etc. Sets flags on the folder.
• Folder discovery iterates over filesystem names, and uses those names for the UI
  => some names are tweaked/localised when mapped to UI, eg "INBOX" -> "Inbox"
  => TODO: where is this mapping performed?
• should users be able to copy folders across OSes? This means enforcing a superset of naming rules. eg Treat Stuff and stuff as the same folder, even on case-sensitive filesystems.
• Numeric suffixes sometimes added to deduplicate... eg "INBOX-1" (TODO: why is this needed? How does it work with folder discovery?)
• some name extensions have special meaning (eg .sbd is used to distinguish subfolders) .

Windows filename rules: https://docs.microsoft.com/en-us/windows/win32/fileio/naming-a-file

It would be nice if filesystem naming schemes were entirely handled by the appropriate mailstore, but currently there are a lot of places all over the codebase which make assumptions about the filesystem. Maybe over time this can change, particularly if new mailstores are added which aren't directly filesystem-based (eg a database-backed store).

IMAP folders

• TB queries IMAP server to find remote folders.
• Base IMAP has ascii names, but extensions handle full unicode (TODO: confirm)
• Takes time to ask server. Usually, if there's a mailstore (filesystem) folder that will be picked up first.
• Missing mailstore folders are created as needed (TODO: identify code that does this). Eg, for a new TB install.

Folder URIs

• Full identity of a folder within TB
• stored in VirtualFolders.dat, and elsewhere
• what are the current encoding rules? What should they be?

=> I think the folder parts of the URI should be UTF-8, then percent-encoded. For example, a subfolder of Inbox called "はい/いいえ" ("yes/no") would end up with a URI something like:
imap://bobsmith%40example.com@imap.example.com/INBOX/%E3%81%AF%E3%81%84%2F%E3%81%84%E3%81%84%E3%81%88

VirtualFolders.dat

• Contains URI of virtual folder to create
• Upon loading, creates a nsDBMsgFolder with name and parent folder based upon URI
• see nsMsgAccountManager::LoadVirtualFolders() and nsMsgAccountManager::SaveVirtualFolders().

Here's a particularly extra special one - on macos there is a difference between composed and decomposed utf8 chars, meaning the folder name is not what you think it is if using it for a key. Manifests in Bug 1219084 and maybe elsewhere.