whtrbt7, I agree with all your points except this one. It's
not up to Google to make Android easier to upgrade.
The reasons why it's up to assemblers (Samsung, ASUS, ...) to create updates, and why they're slow at it, or sometimes unable or unwilling to do so:
- Hardware drivers
- UI skins
Blocking factor 1 - Hardware drivers
By the time a new version of Android is to be released, the kernel has been upgraded as well by the Linux team. Google have their own fork with Android-specific patches but the bulk of it is untouched.
Some hardware components (often times: GPU, radios, Wi-Fi, Bluetooth) require drivers (kernel modules) that aren't part of the Linux kernel or the Android fork. Since they're not supported or even tested by the kernel team before release, third party manufacturers have to continually keep up with kernel updates. They don't necessarily do a good job at it.
Some drivers are open-source. If the license allows, the assembler may update it on its own. Otherwise, as well as for closed-source drivers, assemblers rely on these third parties (themselves in the case of Samsung) to be provided with updated drivers so they can integrate it in a new Android version and make a custom release for their tablet.
The whole process of updating -- or waiting for third-parties to update -- kernel modules for hardware parts, to keep up with the updated kernel version in new Android releases, is one factor for their slowness.
Even Google's own phones require closed-source kernel modules (
distributed as BLOBs). So, to me, the hardware-drivers argument is acceptable.
Blocking factor 2 - UI skins
Assemblers, as I imagine, during their days-long committees, have concluded they *need* to differentiate from the competition. Who cares about what the end-user really wants (plain pure Android in my case), or if their product is better, as long as it's *different*

. They'll even throw in unremovable crapware (sometimes trial versions), so they can add some more bullet points to their features-list.
Adding battery draining widgets, tearing apart existing good UIs, adding crapware, locking down the bootloader, creating a web-based bootloader unlocker (for rightly furious users doing them bad press on social networks)...
All this takes a long time. Especially when everything has to be redone from scratch after a major Android overhaul (2.3.x => 4.0.x).
Conclusion
Google releases source code for Android, for assemblers to use. It's generic only up to a point (drivers). The stock version can't run on all hardware. Assemblers then need to acquire or make drivers for the updated kernel. And crap up the UI and bootloader.
I think Google are doing their best as it is. I can't imagine how they can avoid fragmentation. Within a model where they don't control the hardware, and allows for their OS to be customized, fragmentation is the assemblers' and internals manufacturers' fault.
I like Microsoft's approach with Windows Phone 7 where they control both the OS and the drivers (and as a consequence, the internals ending up in tablets and phones), yet leaving assemblers some leeway to package those up in custom chassis, with custom displays. I don't know enough about Windows 8 but I don't think it's the same model (this would be a shame).