just re-read the thread, and thought I'd post a few other points

• we're also not happy with the persistent cookies problem (the reason you have to log in regularly), but it's an asp.net 2.0 issue, not a dotnetnuke specific one. IMHO it's a security flaw in the 2.0 implementation of forms authentication cookies (a point I debated here with no satisfactory answer from MS - http://forums.asp.net/thread/1347393.aspx ). I've already created and tested a workaround for this, and will be checking it into source tommorow.
• we have plans to move to a webfarm to support the increased traffic, we're just waiting on a few factors to happen (hardware arrive, people have time to test and implement). This should help greatly
• the forum module comes from code that belonged to a coreteam member, that was generously donated.It was not 'traded' for a core team badge. Whilst the codestyle may be different from typical corecode, it has been closely integrated for quite some time, and will continue to improve thanks to the hard work of crispy etc. Having our own forums module allows us to react to our communities needs, and also is an expected bundled module with virtually all portal products. I don't doubt that there are other modules that are better/faster/more featured in peoples opinions, but using and building our own module benefits the community IMHO. Throwing all of this out, and starting from scratch would be a lot of effort, effort better suited to improving the existing module (my opinion, you're welcome to disagree, as I'm sure many of you will *grin*) DISCLAIMER: I think that activeforums is an excellent module, one I've recommended to my customers - just because I prefer we work on an opensource module that's free to download, does not mean that I don't recognise that commercial modules such as activeforum may be better suited to certain sites/clients.
• don't forget we're often dogfooding code here - just because it says it's version 4.3.4 here, doesn't necessarily mean it's 4.3.4. At times it's necessary to push code changes/database changes into the live environment as patches to test, rather than doing a fresh build. Succesfully tested code can then be rolled back, and rolled into a build, which can then be dogfooded with greater confidence. This does help ensure higher quality releases, but can have unwanted side effects -it's better we catch them in our environment than distribute them across thousands of portals.

Cathal