which of these approaches sounds best to you?
The Treo 650 has 312MHz RISC-type StrongArm/Xscale processor, 64MB RAM and 320x320 display. There are several full C++ development environments for it, including CodeWariror (old and costly, but good) and Eclipse (free). There's even a complete C/IDE that runs on the Treo itself. The programming model is strikingly similar to the old Mac OS (pre-Unix) which also was developed in CodeWarrior, with the main drawback being that multitasking is cooperative, rather than preemptive and so while batterly life is greatly enhanced, running background apps (which is kind'a important on a device that doubles as a phone) is always a challenge. Also, PalmOS is like MacOS in that it was originally born on the CISC-type Motorola 68000 architecture and was later ported to the RISC-type StrongArm (now-called Xscale) architecture using technology that preserves backwards compatibility by emulating the 68000 architecture. Apps that want increased speed by running natively on the RISC chip do so using an awkward API and, of course, you have to run natively to do any kind of audio/video compression/decompression. IBM also offers a free Java VM for the Treo and Opera has implemented a thin-client web browser using it, though the built-in Blazer web-browser on Treo is really excellent. The Treo 650 includes 1xRTT (for CDMA networks) or GPRS (for GSM networks) both of which are like using a dial-up 56K modem (give or take). The newer 7xx models have a smaller display, twice as much memory, shorter battery life and EVDO (for CDMA networks) which is like almost 2Mbps or EDGE (for GSM networks) which is under 200Kbps?
As far as getting Pluto running on Treo, I have my own custom system developed over many years that does most of what Pluto does (Myth, Asterisk, X10, etc..) and I control it from Treo using the Blazer web browser accessing a custom Apache cgi-app on my main server. This allows for rapid changes to the visual elements/buttons by tweaking HTML --better than hand-coded C/C++/Java app. This will also support iPhone or other devices in the future. You could probably make a simple Treo 650 (32x320) web-app that is itself nothing but a client to your existing Symbian "terminal server" app, as gross as that might be. At least you will have empowered Treo users while you come up with something cleaner.
I myself am toying with the idea of switching to Pluto, in which case I could help, but I am on the fence, plus I don't know about how to integrate my customizations (OneWire, Growl, RS232-based sensors, etc..) in such a way that they don't get wiped out by the automatic update process. Also, I would want SELinux and jobs that launch off of read-only media running all the time and checksumming/MD5ing every file on the disk to ensure nobody has tapped the system --so updates can only happen after I've updated the signatures on the read-only media. Not sure how much info is being phoned-home to Pluto in update process either, but I am just getting into your docs/website.
So conclusion is this could go eitherway, simple web-app hack to empower Treo today and iPhone tomorrow or full blown C++ recompile with custom classes that call upon the PalmOS graphics and Bluetooth/comm libraries.