A set containing some strings and some objects doesn't make much sense and if you switch from a set of strings to a set of objects than the way the set is implemented will be the least of your worries. You'll have to change lots and lots of other things. Besides in such a case Tie::RefHash might very well be enough.
You can't presume all future requirements. So any futureproofing is bound to fail.
I doubt any module is as well tested as hash operations.
A set containing some strings and some objects that behave as strings makes perfect sense to me. For example, a set that contains some strings from user input and other strings that live in a DBM::Deep DB.
No, I cannot presume all future requirements. But, I can presume that many future requirements will lead me to places that other peoples' future requirements led them. Therefore, with sets, I can guess that many future requirements will probably require one or more advanced set operations.
Given that most sets are implemented as hashes, this is a non-starter. And, the issue isn't one of whether or not the hash operations are going to work. The issue is whether or not my implementation of the pieces of set theory I need will be as correct as that in a well-used module. A hash is not a set.
My criteria for good software:
Does it work?
Can someone else come in, make a change, and be reasonably certain no bugs were introduced?