I did get a couple of hours of coding in on Saturday morning, and it looks like message metadata persistence is almost complete. Another couple of hours should see metadata persistence at the mailstore/folder level working. I think that's all I need to start testing the scalability of the mailstore. It'll be interesting to see how all of my assumptions pan out when the rubber meets the road. (Well, interesting for me. You all probably couldn't give a lick until it's "5 - Production/Stable".)
I haven't decided yet whether to support user-defined flags, and I don't know whether it's important to cache header fields and body structure--I've posted a message to comp.mail.imap, hopefully someone there will help me out. Hate to say it but they seem like a little bit of a scary bunch--perhaps years of dealing with non-spec-compliant clients and servers has made everyone just a little bit jaded.
I also got a chance to test the code that fetches mail from POP and queues it to the correct mailstore... it works great! I'm really glad I decided to write my own POP client for this purpose instead of relying on JavaMail. I rather value the efficiency I'm getting, rather than trying to abstract away the mail implementation as JavaMail does.
Also took a moment to comb through the Apache James mailing list archives and wiki to see where their IMAP efforts are. It seems that they are actually on their third ground-up implementation of IMAP, and there isn't much indication that this time around will be more effective than the last two. It may be that there are fundamental differences in the way the James mailstore is implemented versus the way IMAP needs it to work. In any case, I think the IMAP protocol is difficult enough to implement without trying to graft it onto an already-working POP/NNTP server--much better to start with a ground-up IMAP implementation and then add other protocols afterwards.