I've been working on a pin and software compatible Arduino variant for some time, the Zigduino. It is based around the ATmega128RFA1, which gives it a built-in 802.15.4 radio as well as a good deal more flash and RAM than a standard Arduino (128K and 16K, respectively). It is substantially more electrically rugged than a standard Arduino -- each pin can handle a +/-30V transient.
Have you tested the open air transmit range using the supplied antenna? I do not see any estimates in your product description or any of your documentation.
Achievable range is subject to a great variety of variables. Since I'm not equipped to do a range test to the applicable IEEE standards, I decided it was better to not make formal claims as to range rather than to make ones that I don't have full support for.
That said, you should see range equivalent to the base XBee module, which is about 300 ft outdoors, unobstructed. Your range may vary.
Aww I've been waiting for another ATmega128RFA1 product on the market but you've taken away a lot of the extra I/O pins (no second USART makes me sad), and didn't give me enough cost savings to justify the missing pins (I take that back... I kind of like it more now). Hopefully you can break-out more pins in another revision
Although it's great that you've made all the pins 5V compatible, I have found myself almost exclusively using 3.3V components now-a-days. If the cost of making more pins 5V compatible is prohibitive, know that at least I myself would not care if you took away 5V compatibility.
It's 2011, 5V logic is dying
Other microcontrollers with built-in 2.4 GHz RF are not as beefy as the ATmega128RFA1, so taking away pins would be taking away one of the only things that makes the ATmega128RFA1 unique
Dying != dead; most of the shields currently for sale listed on shieldlist.org are 5V. I'm looking into ways to pull the other two ports out for the next revision.
I'm talking to the uracoli guys about porting that over, and offering free hardware for porting uracoli and contiki. Dropping a line to the uracoli project might make it happen faster.
There's a good chance that Atmel simply threw the silicon from the standalone transceivers into the MCU, eliminating the need for a SPI interface, meaning porting over existing code should be as easy as replacing some SPI functions. Hopefully this is the case.
There's a high probability that they did exactly that. I'm told that's a very common approach for companies making their first SoC products. Inspection of the PAL/TAL/TFA modules in the Atmel MAC also tends to support that assumption.