|Pathologically Eclectic Rubbish Lister|
One thing that will surprise people is that it contains no provision for numeric comparison, so by the numeric/string duality, numbers will be compared as strings.
Yes, I agree that this is the biggest weakness of the suggested rules.
The problem of surprise could be partially mitigated by emitting a warning when a numeric literal is used as the RHS of a smartmatch (or as a when-expression), but of course numbers coming in through variables would still silently use string comparison.
As for there being no way to employ numeric comparison, in theory people could create a Num class that overloads ~~ and forces numeric comparison, but such a solution likely won't be worth it to users of smartmatch or given/when (since the whole point of those features is to make things simpler).
Not ideal, but also not necessarily a deal-breaker.
Of course, I would love to be proved wrong regarding separate string/number dispatch not being possible to do safely in Perl... :)
All good points. I guess it's better to leave those rules out then.
As for junction semantics, it occurred to me that the problems/warts of the existing Junction module(s) on CPAN would probably go away once ~~ like described above (but without the three "bonus" rules) is in core and those classes have been updated to overload it (rather than relying on hacks like overloading == for non-standard things.
So, support for $topic ~~ any('foo', 'bar', qr/baz/) would then be provided by those modules and would not need to be hacked into the smartmatch operator itself.
And if, at a later time, one of those junction modules makes it into core too, then all the better.