The Galaxy Tab, may not be able to compete with the GPU performance of the iPad2, but it still looks like a very compelling purchase for many individuals that don't fixate around specs -- or games.

http://www.engadget.com/2011/03/14/s...-look-all-tha/
(as linked before)

However, Google should consider improving on what exists than hunting newer features for Honeycomb tablets.

For example:
1) Continuing to modularize certain APIs out of the Android OS distribution. This will make it easier to 'push' updates. Which leads to:

2) Consider using Dalvik for developer libs (increased portability) and not just app code. Dalvik has come a long way in terms of performance (computational and memory) and it will likely make a fine substitute for otherwise compiled APIs that require OS bundling.

3) Improving on existing features rather than constantly adding new features. Certain bug-fixes can be applied to greatly improve the UX as well as enhancements to usability and speed.

4) A binary testing mechanism to ensure proper functioning prior to integration on a new system. Somewhat of a novel concept, but it would protect users from a failed automated update, and provide Google feedback to further improve support of a particular system, or pass that information on to the vendor.

5) Store multiple versions of core libs on drive (if it's not done already), with a rich manifest describing the particulars of the lib. This will allow a good mix of homebrew and external APIs for developers to use. If coded in Java, the benefit would be a lib almost 'guaranteed' to work on multiple platforms.

6) Provide a mechanism for community developers to easily 'try' OS code on their systems in a protected way for increased community interaction with bug-fixing. Empowered, the community would lend a great hand in improving the overall stability of devices across the spectrum, and be encouraged to try new APIs.

7) Allow the storage of libs in the Android Marketplace in a hidden form (non-purchasable). Apps would thus be able to list their dependencies, and dependency chains could be resolved via Google's services. The download would be 'apt-get' like, only with static APKs rather than expandable debs. Similarly the lib would be subject to the same access permissions as with applications.

8) Provide access to vendors to upload things like binary kernels, modules, and native libs to the market in a hidden form (if it's not done already). This will remove the difficulty of pushing updates and will not require special software outside of that which ships with Android.

With these inclusions, Android could see seamless updates not only to apps, but core OS functionality. Instead of requiring that vendor's update the OSs, Android could receive timely updates and all devices could slide between OS releases. This provides more of an opportunity to fix bugs, as well as to distribute APIs and even to try new features!

The manifest features, testing and versioning ensure that current software will not break in the event of an update, even a significant one.