The wallet doesn't have coins in; it has keys in. Therefore it doesn't matter how many coins are in that wallet when it is uploaded; it matters how many might be in it in the future. It doesn't matter that it will be encrypted in the future, it matters that it's not encrypted now.
This is a great point, and we'd most likely force the creation of new receive addresses (and therefore keys) as part of an upgrade. I believe this would solve it no?
You'd have to make sure you blanked all the pre-created addresses too; and of course that you didn't overwrite existing addresses which might have credit on them. Then warn the user that they should transfer all the credit they have on those current addresses to one of the new, safe, ones.
That would probably do it.
I do like the idea of a wallet that is part of my google account; but I don't trust google enough to put real money in a place where I have to trust every employee who has access to their cloud storage (which will be a huge number of them). The ideal solution then is a shared wallet with strong encryption using a password that I have to enter before sending any bitcoins.
It's still not perfect because you're relying on computing power never increasing sufficiently that your current secure password becomes insecure in the future. Therefore you also need an option to not share the wallet in the cloud, and allow me to back it up manually should I so choose.
