I can see that some might see it that way, but it's not really the case. Adding a mandatory javascript app layer to an OS doesn't add functionality, it takes it away (less battery life/performance). You can't do anything new with it that can't be done better without it. I.e. not really a feature...

It's rather like Apple calling the no user multitasking a feature, or the nonremovable battery. Both are "features" that restrict user options.

Edit, rather than continue posting off topic: i can see the point that it is a feature to developers in your reply, but would argue that in this case that does not imply a user feature, and here's why.

First, battery capacity is the one mobile device hardware component that is essentially stagnant. The only way we get better battery life is by using a bigger battery or making the software or hardware more efficient. Moore's "law" has made a pocket computer phone a possibility in the N900, but we already know the M6 device is going to be using the same SOC--in fact, it's almost going to be the same as the N900 in hardware--so we're really not getting a significant bump in efficiency from the hardware. At the same time, we'll probably see more RAM and hopefully a magnetometer and bigger screen. It seems to me that the N900 has sufficient battery life, but only just.

Now, given that, what would your strategy be to evolve N900/Fremantle into a killer device that is going to rule the high-end mobile device world, one that will be light enough to get greater market penetration and have battery life to break into the much larger market of people not specifically looking for a computer?

Well, i'd use step 4 to hone and refine the software and drivers so that step 5 can slim down and last longer. So that it actually represents the lean, mean product of 5 steps of evolution, rather than the fifth step in a tech demo random walk.

Let's see Nokia's plan: hey, let's throw in an extra layer of cruft that takes up a large chunk of RAM and more cycles. Maybe we can draw developers from Palm, Android, and iPhone so that we can pad out our repo with lots of shiny apps and won't have to use these old boring compiled ones our community has been polishing and refining for a few iterations. By conforming to the rest of the mobile device world, we can really make our product stand out. After all, we have universal name recognition as a provider of great apps, ergonomics, PDAs, and polish. Why would anyone in their right mind not flock to our banner then?

Hmmm. My second point was going to be that reducing the barrier to developer entry to that degree doesn't promote useful development or apps, but i don't really think a second point is even necessary. This has all the earmarks of a pointy-haired manager at the wheel, so i guess we can just hold on to our owls and hope for the best.