Unfortunately the Python API is also not consistent between the game engine and the rest of Blender. Erwin and me wanted to work on that but there was just no time left before NaN went bancrupt the first time. And I had other problems to survive in London
Thanks, Jan, for everything!
My priorities would be:
1. revise the python system to give scripts access to more parts of Blender's internals, including the GUI. Ton talked a bit about this at the conference, and the problems now revolve around Blender's "event system". He thought there might be a way to get python "hooks" into those areas, and this could allow all sorts of additions to the GUI. It might also help in "pythonizing" the plugin/material system.
2. smooth the gap between realtime and offline python. markluffel's comments are right on -- at least in terms of integrating realtime and offline. It seems that if you kept the python context (namespace) constant between running an offline script (gui in a text window) and the game engine, you could definitely handle his example of "baking" realtime behavior into ipo's (there's a script available somewhere that records game objects' properties to a file for offline translation into IPO's).
How about running your python gui script, being able to set variables in the GameLogic module. Then if the offline API had a "startGameEngine()" method, the gui script could start the game engine, maybe even advancing it frame by frame with "advanceGameFrame(). When the game was finished you could access whatever variables your game scripts put onto the GameLogic module, and the gui script could continue running. If the offline API also had access to the logic bricks, then much more would be possible. With the new ODE physics system, offline python programmers are really going to want this functionality!
These things, to me, would be the "low hanging fruit" that would pay off big time. Yet bigger things are good, too. Actually, Ton suggested that a version 2.5 could have an expanded "constraint" system, such that "parenting" is handled with a type of constraint possibly subject to IPO's like in v.2.25. The great thing about open source is that big and small projects can go on in parallel. Sign me up for 1. and 2.!