I'll contribute something on the issue of whether to do redesign now or later. The conversation you're having parallels some discussions we've had here. The debate over whether to use the content repository recapitulates a discussion several of us had last August. The design is being changed for the next version. The design for messaging, and mail, etc is also changing.
Design questions generally take a long time to resolve. You'll deliver a working product much faster if you put off the design questions and just port the queries. Its not as intrinsically interesting a project to work on then, but you get something usable faster. Also, since you are matching the ACS 4.0 requirements and design, you have a concrete base line to evaluate your results against. This makes the port much easier.
War story: We had the opportunity to make design changes for the ACS Java 4.0 port. We decided not to. The only new code and design was infrastructure to make the port possible or easier (similar to the QueryDispatcher idea). Otherwise, we kept the design the same. This allowed us to port the code in a definable and short period of time. Introducing design considerations makes it much harder to deliver code by a certain date.
What I would encourage you to do is to refactor the ACS code. If you are porting a query or method and see a way of making it clearer or removing a bug, you should change that. I wouldn't add features, as they add to your testing and documenting load.
Hope this is helpful. Much of the reason the ACS is the way it is is because we prioritized our own client needs above technical aesthetics. Unless you identify a fundamental problem in the design, such as a scaling or upgradeability problem, getting the code to the user sooner has a better payoff. The users will have your code, be doing interesting things with it, and giving you feedback on how to make it better that is often much more valuable than any internal design discussion.
