The way I see it a lot of how this machine will be received is involved in how much a feel of professional design and support the buyer feels when they open the box and fire the unit up, or begin to run software/develop for it. When the GP2X launched no real SDK was provided (not to the extent of which the impression was given would be included, anyway), and a lot of aspects felt unpolished and just out of place. I won't go into them because I think everyone who has owned a unit would have come to the same general opinions.
The biggest of these I think involve the system having everything the average user needs right out of the box, like a rechargable internal battery, AC adapter, and a USB cable to link to a PC..... no need for a customer to buy extra batteries he doesn't know about, no need to buy a charger or cables. Everything pre-assembled, no installing your own LCD lens..... It also can't feel like a toy when it comes out of the package.
But a lot of these things are software too. In the early days of the system there will be unstable software, and even in the later days. Software will have bugs and it will crash. And this may drive a lot of users crazy, who wants to power off and back on and launch it again, when so simple an option exists as to have a background process running to catch program crashes and return you to a menu. This could be a feature that can be turned off, if it becomes a serious performance issue, which is very unlikely with such a powerful chipset as is being discussed.
Some other things.... for users of emulators it would drive lots of people crazy that their interface is nonstandard and so are the button assignments. Here is a idea... how about if developers can use a common series of globally set values for button assignments in their applications. These can be set in a system 'control panel' so to speak, along with other settings like to turn the 'crash catching' process on or off. the machine is obviously meant to work more like a multipurpose PDA-like device than just a pure game console you put a game in, turn on, and turn the unit off to stop playing, so this makes sense anyway. Being able to operate the device in a multitasking environment would be welcome anyway and some fault tolerance for crashed processes is a critical aspect of that. Same for being able to return to the menu without shutting the unit down.
As a developer I would consider one of the most important aspect to be able to start developing for the unit right out of the box, and that means provided development tools, an IDE, compiler/linker, libraries/headers needed. While Paeryn's hardware-accelerated SDL Lib was nice to have it is something that should have been provided from the makers/distributors of the GP2X in the first place, and such should be the case with this new handheld. Same for an easy set of libraries to get at the OpenGL API, use OpenGL contexts w/in SDL apps, so on and so forth. Developers who want to work at the lower hardware level just need proper documentation available to them so there are no 'secrets' in the hardware. And as someone who wanted to develop for the GP2X from the start I can say that if I buy one, I want to be able to bang out some software in SDL and see what it is capable of and not have to worry about "is someone in the community, unrelated to the company making the handheld, going to come out with software that lets me do that?" an open handheld needs a proactive company standing behind it, empowering developers from day one.
Just some ideas I hope are well received.... sorry for the length of my post.
edit: double post...... in one post! awesome!