You’d do a great scammer 
But I don’t think this kind of attack makes sense: wallets should make it perfectly clear that you are adding a contact that will be associated with the given “payment code” (or some other wording). I don’t see how Mallory would be able to lure Alice into this flow in a credible way, Alice knows that she’s not paying Bob and this payment code wasn’t generated by Bob.
If the contact key gets compromised, it likely means the organization’s seed got compromised, so they lost all their money…I think having their contact key compromised is the least of their concern if that happens!
But this is indeed annoying, because the only thing the organization can do is notify its users that their contact key has changed. This is somewhat similar to having your users’ passwords being stolen, in which case you must notify them all. This isn’t great, but I don’t think it’s critical either.
You should be able to associate multiple keys/offers to contacts. I don’t see a reason why that wouldn’t work.
Unfortunately, I don’t think we can do that: businesses and protocols will likely want to use that payer_note, and will train users the other way, telling them to look at this field and ignore the wallet’s recommendation…so I’d rather have a way to make this safer, even though it will never be perfectly safe since keys can be compromised 