As you say, each approach has its pros and cons, but depending on your requirements there is a solution which can fit for each requirement. Augmented instruction sets (SIMD units, etc.) can provide a good level of flexibility when targeting graphics rendering. The Cortex A8’s Neon unit is a prime example of this, but when pushed to support high end features (such as advanced texture filtering, FSAA, etc.) it becomes constrained by the CPU’s memory interface, which naturally is optimized for the access patterns of general purpose processing, but not graphics processing.
The adjunct GPU approach allows for easy addition to an existing system, but suffers from having a relatively low bandwidth connection to the main CPU. This creates a performance bottle neck for these systems as all the data (textures, geometry, etc.) used by the GPU will have to be squeezed over this port. These ports also generally operate on a “push” model requiring all the data to be “pushed” to the I/O port by the CPU, tying up valuable CPU cycles that could be spent on an application.
To ease this problem, adjunct GPUs often contain embedded RAM (DRAM or SRAM) which the GPU uses as for caching data, local processing space and for storage of the frame buffer. This approach has a few drawbacks however, as it prevents the efficient sharing of memory resource (you basically have a relatively large block of memory that can only be used by the GPU) and it also prevents the ability to mix rendering from CPU and GPU (a technique common in MIDP2 implementations).
For the mobile industry the preferred choice still remains integrating the GPU into the SoC and using UMA memory architecture. The Mali range of GPU’s has been designed with the constraints of these environments in mind.

Today, JSR-184 is a very good API for developers to create 3D content. Java is the most popular execution environment made available to developers and for them, there are few options available for producing 3D content. The developer can try to create 3D graphics using the 2D API available in MIDP, but this will be a very slow process and the graphics will look quite simple, or the developer can use one of 3 APIs: JSR-184, JSR-239 or MascotV3.
* JSR-184 is a widely deployed API shipping in hundreds of different handsets from all of the top handset manufacturers, so it gives a good customer base for developers to sell their games to. There is some porting required between each phone, but the effort to port a JSR-184 game can be less than the effort to port a 2D game because the graphics will automatically scale to the correct screen size. For example, content developed for Nokia phones that use Nokia's own JSR-184 implementation can be run on Motorola phones that use ARM's Swerve Client JSR-184 implementation and the 3D graphics will require no modification. Hardware acceleration is not required for JSR-184 devices, but many phones do now ship with an OpenGL ES 1.x hardware accelerator such as the Mali55, and the Swerve Client will make use of this to allow the developer to use much richer graphics and achieve a high frame rate.
* JSR-239 is quite a new API which is designed to allow programmers to use the OpenGL ES API from Java applications. There are no phones using JSR-239 and there is no content that uses JSR-239 except for one benchmark so it is too early to consider JSR-239 as an established standard. Judging from the uptake of JSR-184 it will take about 2 years for JSR-239 to become widespread.
* MascotV3 is a proprietary API that is used in Japan. Developers should use MascotV3 if they are planning to sell their content in Japan, but otherwise JSR-184 will give the developer a larger customer base.

In the future as native execution environments replace Java we will see the native graphics APIs such as OpenGL ES and OpenVG being used instead of the Java APIs, although it is likely that for some classes of games developers will continue to use a scene-graph engine such as ARM's Swerve Client in order to speed the development time and to enable them to easily port the games to those devices that still use Java. The Java platform is increasingly being used to deliver services beyond 2D and 3D games such as push email, instant messaging and music players. The problem with Java is that it must be translated (from bytecode) into the language of the underlying hardware (ARM) at runtime, when the phone is executing the application. This often results in unacceptable performance. There are two basic ways to speed up performance of Java that are in use today:
1. Software only techniques, such as Just-In-Time (JIT) compilation. This requires a Java-to-ARM compiler running on the device, which compiles the Java bytecode to ARM instructions. The downside here is around a 25% increase in static memory size due to the compiler, a 3 to 8x increase in application size due to the expansion of bytecode when it is compiled to ARM code and often unacceptable pauses caused by the running of the compiler during game play.
2. Hardware acceleration, such as Jazelle DBX, where the majority of Java bytecode is executed directly in the processor core. The ARM core treats Java bytecode instructions as the native instruction set of the processor, so achieving near-native performance with no memory overhead and smooth, consistent application behaviour.