And if I prefix my error messages with "MyError::Foo" you'd have to explicitly throw an error that started with that string to break my error handling.

Right, which can happen a lot, since I don't prefix my errors and often build error messages dynamically. So if my error is "MyError::Foo instance cannot be passed to do_something()", your error handling breaks. And it doesn't even do it consistently, it'll break depending on what I want to communicate to the user.

Yes, bad namespaces are a problem. But there's no namespaces in error messages. It's all just a message. And while you can define for yourself that the start of the message is "the namespace," I'd rather use inheritance, since that has dedicated namespace functionality.

Again, exception objects are for communicating with the rest of the program. Error messages are for communicating with the user. If you mix the two, there's worlds of pain down that road. Not to mention the fact that exception objects can carry optional stack traces and various other information, which makes them even more valuable to the user, even if it's just to communicate a better description of the error to a developer.

If you really think $foo eq "bar" and $foo->isa('Something') are exactly the same, I'm quite concerned.