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).
So I guess the case of numeric comparisons simply won't be covered, or rather, people will be forced to write it out verbosely:

given ($_ == 5) { ... }
$foo ~~ sub { shift == 5 }
[download]

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... :)

I have my doubts about the cases you're not sure about; distinguishing barewords from strings is impossible in non-strict mode (which I rarely use, but which is still a big part of perl, whether you like it or not).

Ranges become flipflops in scalar context and a list in list context, so doing a range comparison seems pretty much inconsistent with the rest of the language.

Comparing lists with any-semantics requires the right-hand side of the ~~ to be evaluated in list context, which IMHO would be a bit surprising.

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.