Overriding an existing file operator (like: -e $filename) is very bad idea. I stick to that opinion. The issue is when I see a line like that in some huge amount of code, I expect -e to do what it normally does without having to read any previous code that redefined that operation. And BTW, I don't know how to redefine -e either.

In this case, I would make a subroutine that did the desired test and use that. In terms of execution efficiency, I see no difference. In terms of source code, there would be a huge increase in clarity.

The benefit of overloading it, is that existing code "does the right thing", given whatever the new underlying context is, everyone can use the old idioms, even though they aren't quite the same.

In fact, a good overload would not lose functionality on normal arguments. For instance, what if someone wanted to instrument logging by absolute filename, to collect statistics? Extending -e to do this would be easier than replacing every file test operator call everywhere, including external packages.

For these kinds of questions, it's better if we get a real sense of the OP's ultimate goal and purpose, before declaring "that's a bad idea" just because it usually is.

-QM
--
Quantum Mechanics: The dreams stuff is made of

-e is broken on windows, it doesn't do unicode

Win32::Unicode does do unicode , but it can't override -e

So win32 people can't use -e on win32

You're still not authority on what should or should not be done