Nums, I'd say you should stay focused on the C++ version. I'm just filing bugs on 2.4A as I find them mostly because I can I guess, just to have a record of them to make sure they get picked up in the C++ fork (yea, I know. I expect the value of 2.4A bug reports is marginal for the C++ fork given the magnitude of the re-write but what the hey...). I'm not on a mission to make anything specific (like leagues) work in 2.4 - just fixing crashing bugs at this stage - though if there is high demand to make a specific feature work in 2.4 that used to work in previous versions, I could probably be of some use there.
I have a pretty fast machine, so it's pretty easy for me to run things in VB all the time and identify/investigate/fix simple things as/when I hit them. I don't really have to know the code that well to fix simple overflows and such, not in depth and those who do know it like yourself are IMHO better utilized working on the new architecture and the port. I certainly don't expect any more 'official' work on the VB fork given the focus on C++ and I'd be happy to share my private VB exe with anyone who can't build the post 2.4A cumulative fixes themselves. I'd also be happy to spend a little bit of time (ephansis on 'little') making specific functionality work in 2.4A if someone really needs something (I really miss the gene activation form for debuigging bots and may spend some time on that this week) but at some point in the not too distant future, I plan to volunteer to help on the C++ version so I don't want to do too much down level....
So, I do think we want to track 2.4A bugs, expecially crashing bugs, but that doesn't mean you or anyone else has to fix them much less make specific features work. My vote is to keep the big guns full speed ahead on the C++ port.
If someone is dying for something specific to work in 2.4A, let me know and I can spend some time on it, letting Nums work on the real deal.
-E
