Still waiting for my drones to dig up some info - all I've got for now is from one member of the FP dev team (desktop branch) is that there were no official strategy changes within Adobe in the past 2 months, which indicates that either the potential support for Maemo was dropped much earlier, or that something happened on the business side between Nokia and Adobe, or within Nokia itself. However, that is nothing more than a speculation. The only solid info I still have is that both Maemo and webOS versions were quite ready (from the technology point of view) months ago and that the Android support was what was holding down 10.1 release for mobiles, what changed in the meantime and why you get lately only Android mentioned in Adobes' press releases still eludes me...

Except that the most work done here is at Adobes' side - Nokia would essentially only have to distribute it within some of the future updates. Plugin wrappers and framebuffer renders are directly portable from any given Linux version of the plugin, so Adobe only had to change the core - AVM2 and graphics handling (incl. video rendering). The VM part is essentially the same across all mobile platforms based on ARMv7, so they would have to do that either way; the second part can be a combined effort of the plugin they are already developing for the Linux as the both boil down to the X Window System and its core gfx libs, while the HW acceleration is the same deal with maybe a slightly different packaging for all OMAP 3430 platforms (and Motorola Droid and Palm Pre both use the same). So, developing a Maemo plugin is certainly not a money waster given that they would do most of the work either way.

Further, Maemo 6/Harmattan/MeeGo are essentially the same platform from the Adobes' point of view, and if the upcoming device from Nokia will be indeed based on the OMAP 3430 SoC, the plugins should be compatible on the byte level w/o even need to recompile. Which only strengthens my belief that if N900 is not getting the 10.1 - it's a business/marketing decision.

If you were to put a watt-meter on a HTML/JS page that does the same that a Flash page does (of course, HTML/JS combo, even in the full-HTML5 draft support flavor which doesn't even exist yet, cannot actually do many of the things Flash does routinely) you would be not scared, but terrified! No JS VM comes even close at instructions/watt performance of AVM2. Flash, when used properly, is far more efficient than any HTML/JS implementation out there.

It does, and in a huge way at that. CPUs (at least in CISC flavor) are jack of all trades but master of none, GPUs can do much less than your average CPU can, but what they do, they do far more efficiently. One of those things is complex number crunching which is really important for things like video decoding, encryption and, of course, 3D rendering and composition (well, anything that has to manipulate a large number of pixels). If you leave the decoding to GPU, you would waste far less watts per video frame than if CPU would do that. Even vector gfx processing can benefit from GPU acceleration as it also boils down to complex math.

So, you are blaming the technology for the faults of developers using that technology. You can build a processor hog in pretty much any executable language, that doesn't say anything about the platform/language, but says a lot about the developer. If Flash was to disappear/become replaced by HTML5/JS combo, where do you think those bad developers would go? That's right - they'll switch to even more inefficient technology and make you a living hell of web experience - now you can at least disable the plugin and you can easily block those obtrusive adds, just wait for the day where you would need to build a CPU-hogging ad blocker that targets only specific parts of the DOM and JS - to stop CPU-hogging ads...