This is an interesting point, that I've thought of as well. The advantage to a console-like hardware arrangement is undoubtedly, lower development times (singular target, less testing), and increased opportunity for low-level optimization (ie. assembly inner-loops).

The downside is generally applications that are obsoleted with device iteration. Traditionally, backward compatibility on consoles has been through official emulators; which is vaguely reminiscent of the iPads app 'scaling'; which is not an emulator though a specialized case to handle older apps.

This just a continuation of the conversation as I agree with your post!

It will be interesting to see which strategy proves more successful. I'm inclined to think that the Android strategy is more suited to an ever evolving eco-system (think debian-esque repository) as apps are not limited to one-device and will live on after the device becomes old. In other words, I forsee the market continue to grow, rather than being divided into multiple concerns.

As an aside....

It's interesting to note that one of Google's technologies NaCl (or PNaCl specifically) can handle native code across multiple architectures at native speed. This is a planned component for Chrome OS, and will likely find its way into Android at some point (if not only in the browser). This technology give its implementers (Google, Nokia, Intel, etc) the benefit of to-the-metal optimization without sacrificing binary portability across disparate architectures! So far PNaCl is targeting ARM and IA-32 (or 64, I'm not sure).