Hi Jim,
Also, change (in the 0.4.23 release and the coming 0.5.9beta release) now goes to the SECOND address in the wallet - if it exists - so that the initial key is not used. This I put in as I found people were importing keys from "somewhere" and then not liking that the change was not going to one of their imported keys. This would also fix change going to a key that was at one point stored unencrypted as you point out.
What if BEFORE importing the wallet contained already more than one key?
In this case people would still experience that after importing keys the change is sent to an address outside their original 'somewhere' wallet.
To circumvent this, may I suggest that you send the change always to the LAST key of a wallet instead of the second key.
Of course people could import keys from multiple wallets or create new keys after the import, giving the same unwanted result as with the current solution (change to 1st key).
But there is an additional advantage to it:
Experienced users who want a 'fresh' address for the change of their next transaction can simply create a new address before spending.
For users who want to obfuscate the addresses they control, this could be helpful.
Because if the change is always sent to the same address this allows to easily track down which keys belong to the same wallet after a spend with change has been made.
On the other hand, if the change is sent always to a fresh address an analysis will not be able to link addresses which send change to the same address.