(1) As I understand it, OP_EVAL is being proposed as an *optional* tool for multi-signature transactions.  It sounds like to me, that you can still use the regular OP_CHECKMULTISIG if you are concerned about these things.  If you're dealing with too many parties with questionable reliability that they will notify you of transacitons that include you, I don't see anything wrong with declaring that you'd only prefer dealing with OP_CMS transactions and not OP_EVAL (besides some grumbling from them that their way is "better").   Either way, they're screwing themselves, too, if they want to include you on transactions and don't notify you as such (kind of defeats the purpose of multi-sig txs).

(2) I think it's unnecessary to discuss cases where you somehow lose your mappings but not your private keys.  In order for OP_EVAL scripts to work, the subscripts/mappings are *just as important* as your regular private keys.  They should be kept in your wallet forever just like your private keys--and thus you lose none of them or all of them.  The only real difference is that they aren't sensitive like your private keys, so they don't have to be encrypted.

(3) There should most definitely be a button on the main client that allows you to "Add OP_EVAL script" or something along those lines (maybe something with a less obscure name).  We need to make it as easy as possible for someone to add such a script/mapping to their wallet.  Although, this invites a breach of one of my core rules of user interfaces:  if the functionality is dependent on the user performing some regular maintenance task, you better be prepared for all users to fail at doing it.  Even diligent users are going to forget/mess-up sometimes.  If failure at performing this task results in breaking the client or losing money, we should avoid promoting that usage paradigm.