A roadmap was put up on the Qcodo Wiki by a couple of other folks in the community a while back, but I think it's a bit outdated. There are a couple of items in there that I agree with (e.g. moving outdated items into QPMs, etc.)
However, I disagree with the concept of version numbering, and that “1.0” means stable. For 5 years now, we have had a concept of both development releases and stable releases, and each release is clearly marked as one or the other. Just because the version number starts with a “0.” instead of a “1.” or “15.” or whatever shouldn't really mean anything. With over a quarter million downloads over the past 5 years, and over 100 million page views per month, I think the Qcodo Framework has shown its stability well enough. =)
I am okay keeping with the set of version numbering... in short, when we introduce a significant number of enhancements and features which will cause at least a moderate amount of breaking of BC, then at that point, we'll bump up to 0.5.x. But between now and then, with all the incremental releases we've got going, I'm okay moving to 0.4.23, .24, .25, etc.
Personally, the main thing I am working on is the integration with jQuery. However, since the goal is to not have any BC breaks after the move, I'm not entirely sure if we'll be moving to 0.5.x for the first release of it, or just keep with the 0.4.x branch. My hunch is that we'll jump to 0.5.x since it's significant enough of a change... but I welcome any feedback on that matter.
Beyond that, the only other thing I'd be interested in doing is switching over the codegen engine to use the PHP Output Buffer, which would then alleviate us from needing to maintain the Qcodo templating language for the codegen engine. I've already got a set of templates I've wanted to add as a QPM package for iOS developers (specifically giving you qcodo-orm functionality within your SQLite-backed iOS app, all in native Objective-C)... but it's a really messy set of templates since it's built on top of the current qcodo codegen templating engine. I believe if we can move to output buffering, then it will spur other devs to more easily/quickly post and share their own codegen templates and tweaks.
There are also some ideas with regards to restructuring QDataGrid and QDataRepeater and getting rid of eval (again, utilizing the output buffer as well). And if we can clean up all of our uses of eval(), then we can begin to look at offering HipHop compatibility for Qcodo, which I believe would be a very big win from a performance standpoint.
Anyway, these are a few of the “big ticket” items I have in mind. Along with that, of course, is all of the smaller things, additions, fixes, etc. that people have been coming with all throughout.