Thanks, jim, four your answers. It all makes sense now.
Have you considered (for solving the "key import rescan" problem) using the help of a stratum server? I'm not sure this is a road you want to go down, but it's probably an option, right? The 
stratum protocol (google doc linked from 
stratum thread) defines a "blockchain.address.get_history" function that could maybe used to identify relevant blocks to rescan. The protocol definition isn't detailed yet, so one would have to look at server implementation to see if this function (or another one) is adequate.
I'm pondering writing a java stratum client/protocol impl for another project.
Hi molecular,
Yes, technically it would be possible to have the network layer of MultiBit to talk to a stratum server but it isn't in my plans.
The current MultiBit code uses the bitcoinj network code (the Peers and PeerGroup) directly so, thankfully, I do not have to go anywhere near the actual socket management. Miron Cuperman has done a lot of work on the Peers - lots of threading work in there - and I use that directly.
I have committed to implementing the client side part of Matt Corallo's server side Bloom filter work so that will be the next network upgrade for MultiBit. The implementation is different to stratum but it's all about taming the blockchain so the end results should be similar. Syncing should be O(the number of keys in the wallet) rather than O(the size of the blockchain) which is a big improvement.
In the refactoring to add in the Bloom filters I want to separate the network layer and the UI layer a bit more. This should make it easier to add in other network connections (hopefully). I can see a connector to the OpenPay network coming up soonish and there will no doubt be other sorts of network nodes appearing in the future.
I think a java stratum client impl would be very useful - not least because you could write a very nice native Electrum Android app with it !
:-)