It is a moot point to discuss if the machine should be capable of 3D or not. A serious deficiency of the GP2X design is the fact that it lacks any real 2D/3D acceleration hardware. There is a blitter, yes, but due to faults in the MMSP2 design, it does not provide any significant advantage over software blitting of graphics.
The designers of this system, whomever they may be, have expressed interest in building a general purpose device, much like a PDA or mobile communications device, that is also capable of comfortable gameplay. In order to keep up with the curve of technology (as well as maintain compatibility with the widest range of pre-existing software), a modern SoC using an ARM-series processor, ideally ARM11 (but ARM9 would work as well) would be the logical route to take. They have also expressed interest in multi-CPU architecture. SoCs from Samsung or Texas Instruments' OMAP series would more than fit this need. The ideal choice, I believe, would be the Freescale i.MX31, but a number of products could fit the bill nicely.
The point is, all of these products provide 2D and 3D acceleration, because in modern SoCs, the two are one and the same. The most common graphics implementation, because it is ARM's reference standard, is PowerVR's MBX architecture. This provides powerful 2D acceleration for very intensive 2D games, enabling enormous gains over software blitting and additional effects very useful for homebrew titles as well as intensive emulation, such as alpha blending, scaling, rotation; as well as a full host of 3D features, high fill rates, and impressive maximum polygon counts (>1 Million).
Such SoCs also implement Vector-FPUs which would be more than suitable for accelerating 3D transform math, or could be implemented for use in intensive emulation, many applications of which require or would be able to make use of a proper FPU. Many modern SoCs also include a programmable DSP with a limitless array of possibilities for its use.
This is in addition to a powerful CPU, often in excess of 500 MHz, which still draws minimal amounts of power. The dual 200 MHz CPUs in the GP2X's MMSP2 chipset give a poor estimation of proper power consumption, as the MagicEyes-designed implementation is primitive, breaks ARM's reference standards, and uses a very old fabrication process, all of which result in excessive energy waste. A properly-designed mobile device utilizing a 533 MHz ARM11 processor, VFPU and MBX 2D/3D accelerator-integrated SoC would not have difficulty attaining a battery life of over 4 hours under typical use, and this is a conservative figure. It's not uncommon to see PDAs attain the same. Use of a WiFi radio would of course decrease this life, as in any device and exact battery life will depend on the capacity of the LiIon battery included. This power draw could be further reduced by implementing software controls to adjust WiFi transmitter power as well as clockrate of major SoC blocks (CPU, Secondary CPU, VFPU, Graphics Subsystem). Modern ARM architecture includes numerous power saving facilities that are not utilized by the GP2X's ARM920T or ARM940T.
If there is anything the GP2X has proven, however, it is that the smallest mistake can cripple a machine if it impacts how the unit is controlled. It is imperative any machine meant to correct the GP2X's faults do away with the issue of nonstandard and cumbersome controls first and foremost.
