~~~... As for autoupdate, that is what we are most focused on. We are working on an implementation that would cleanly and painlessly update the wallet automagically at once. and do all the mumbojambo
Please do think this through carefully - whilst there are technical solutions to auto-update (eg code signing & having the client validate signatures on update packages etc), pools & exchanges must have the ability to disable it and it is very hard to defend against the "one man controls the network" argument - if we want Cache to succeed (and I very much do!) we have to be careful about the perception of centralization.
Here's an interesting post from Greg addressing this topic in the Bitcoin context as food for thought
"Auto update" is categorically not the same as manual updates.
Bitcoin is an autonomous peer to peer system. It's security, its promises of non-inflation, everything that makes it valuable depends on someone not being able to just flip a switch and redefine it. As you say, "there's no excuse" to introduce that kind of vulnerability. Bitcoin was invented to remove the requirement for that kind of trust, and if you're willing to have that kind of trust you can build systems which are much more efficient than Bitcoin.
Someone with the ability to just push auto updates would be an extreme danger to the network, and that ability would be a potential danger to those who possess it by virtue of making them an attractive target. If the core developers start telling you that you need developer controlled automatic update you can assume that we've somehow been compromised.
There are certainly things that can be done to facilitate smoother updates and we should do them: For example, deploying the gitian updater tool for users to use which checks the gitian signatures and saves them some website clicking would be a nice improvement and would strictly reduce vulnerability. (since not that many users bother to check the signatures today when they update)
Any system which would run _automatically_ if any were to exist at all, however, should only work on a long randomized time delay to allow review and alarm if there is a problem and should support negative acknowledgements, the keys for which could be spread fairly liberally.
So go ahead with your "16 coins" run autoupdates for 15 of them. Bitcoin is a decenteralized system and is staying that way.