I guess while it can happen, it must be checked for, so in that sense, I agree with your conclusion for generic solutions, and applaud you for your original mention as it was something I had never considered.

That said, I think I would stil tend to ignore the possibility. If a reference my code is given to deal with has been blessed into a package who's name tests and false, then it is either a diliberate attempt to screw things up, or is the result of an accident. In the former case, the user gets what they deserve:). In the latter, it will mean my code will fail, which is probably a good thing as it will bring the error to the user attention.

Uhm, why? Just because it's inconvenient?

If there was a legitimate (even if esoteric and obscure) reason for blessing things into a false-testing namespace, then I could see the reasons for allowing it.

However, without a legitimate reason, it makes no sense to me to inconvenience everyone with the need to test for it, when a simple test + error in the implementation of bless could remove that inconvenience.

...and Microsoft Outlook...

I wouldn't forbid it, I would make it's use a capital offense with no possibility of commutation or appeal:) I once nearly lost a pretty good job by refusing to use it, and I will continue to do so. Though my reasons have nothing to do with convenience or lack thereof.