Sorry, been there, done that (with Qt, Mobility and PyQt). It's a nightmare, it's just so easy to break/drive the upgrade mechanism into an error that it's not even funny. As for several copies, again, in a weird sense it's the lesser of two evils. When you have a thousand (yes, I'm exaggerating) apps using a shared lib, they will inevitably be using multiple, maybe mutually exclusive versions. When these apps and libs are open source, and have maintainers, all is well - you ping people, they repack, patch, etc. In a store, that doesn't happen - you mostly only have binaries, the users expect them to work even after upgrades, you must rely on the original author to fix whatever is broken, etc. MeeGo compliancy was right about what matters for stores - where it was wrong is that it was linked to logo and name usage and didn't take into account that stores and FOSS repositories can't be managed the same way.

I didn't say you shouldn't have packages, just that debs, rpms (and jars, ipkgs) are unfit (and that's why they were hacked/extended). See how f.e. icons were added into the metadata on Maemo. Apt-repositories (and for zimon, rpm correspondents are not much better are horribly unsuited for large package counts (take a look how much time and memory it takes to update/refresh on an N900 that has all extras* repos enabled). A modern package format (and corresponding repositories) should be streamable, resumeable, filterable, downloadable and installable in parallel, support selective part-downloads, multi-arch, reconstructable, delta-upgradeable, have indexed and easily accessible metadata, etc, etc.