My perspective is that we are trying to never show keys and make it "intuitive" with only names while at the same time treating keys as "higher-class" citizens than names. This schema breaks in worse ways than "I don't get to have my name" when you let people transfer. Scamming becomes easier, making mistakes becomes easier. Fixing it requires a reputation scheme (none I've heard so far are satisfying) or top-down intervention.
I don't think these scamming/spoofing/accident issues are anything a decent GUI design that enforces best practices can't solve. There should be BIG HUGE WARNING FLAGS and annoying confirmation requests anytime you want to send anything valuable to a named account that is not in your contacts list (favorites). Also, in my view the local alias for accounts should take precedence over their global name (and local aliases in your contacts list should autocomplete in the to field of transfers while global ones should not). Let me explain with an example. If I add your account ("nikolai") to my contacts list, it should create a local account with the local alias "nikolai" (and of course it knows the global name is "nikolai" as well). I should then be able to change the local alias to "toast" even though that conflicts with the global name "toast" that is registered by someone else. If I send money to "toast", my client should send the money to you without complaining. Prior to doing this renaming, if I tried to send money to "toast", the client should complain that the BTSX user named "toast" is not in my contacts list and require that I first add the account to my contacts, or if I am
really sure I can press these series of tiny obscure links/buttons to have it go through anyway. This warning would hopefully remind me: oh shoot, "toast" on BTSX is not really toast, I meant to type "nikolai", let me cancel this and fix the problem. I would then add "nikolai" to my contacts, maybe give it the alias "toast" for my convenience, and no longer deal with that silly problem again. It would be even better when we have web-of-trust reputation systems, because if I go to add "toast" accidently, I would notice the surprisingly low reputation score for someone who I know should be well respected in the community, which would then hopefully jog my memory or incentivize me to do further research to discover the reason behind it.
So why bother having these global TITAN names in the first place when we could have just done it with local aliases and active public keys? Honestly, in some ways that might have been the better way to go to avoid so many mistakes people make. However, there is still some value in being able to communicate a free human-memorizable name to other people in a non-digital setting. If I had an encounter in person with someone I just met, and as I had to go they said they wanted to send me a tip, or send me a message on KeyMail, or whatever, and they wanted to know my unambiguous handle to reach me, I could just say "I'm arhag on BitShares X, that's A, R, H, A, G." Being able to do that is useful, so I think there is still value in global TITAN names. What happens if I realize my account was compromised before this person contacts me or sends me money? I revoke my account, then when the person goes to add me to their contacts, their client warns them that this account was recently revoked when they try to add me. What if I revoke after they add me to the contacts? Well, their client will warn them that the account in their contacts was revoked and temporarily disable sending anything of value to that account until the user deals with the issue. The user would have to manually confirm the new global name that I associated with that account (and possible change the local alias if the user desired) or just re-enable the account with their preferred local alias even if I didn't associate a new global name to the account.
Finally, even if people were allowed to rename their global TITAN name to a revoked name, there still shouldn't be many issues in a well designed client. Let's say I really wanted the name "a" but it was taken. But then recently, after telling some new person I met that my BTSX name was "arhag", I discover the "a" name was recently revoked or maybe it expired somehow. I decide to switch my name to "a". Now everyone who had me in their contact list will get the update next time they use the client that "arhag" changed his name to "a". They will confirm this change in the client and decide whether they want to change their local alias for me or not. The new person I met has knowledge that my name was "arhag" still but has not yet put it into their client. Before this new person was able to do that, someone else took the "arhag" name for themselves. Now when the new person I met goes to add "arhag" to their contacts list, they would be adding the other guy and not me, BUT the client can warn the user that this name changed ownership recently. By comparing the time the change happened to the time the person remembers me telling the person that my name was "arhag" this person will know that it is no longer safe to assume this "arhag" is the same person they met. But the blockchain has enough information there to tell that user that the "arhag" that existed at the time I told them my name was "arhag" is now renamed to "a". Problem solved.