There are problems with the design of smart-matching. The decision of what any given TYPE ~~ TYPE should do is most often unobvious, inconsistent and/or disputed. The idea isn't to remove smart matching; it's to fix it.

Specifically, ~~ will likely be greatly simplified, as you can see in a proposal by the 5.18 pumpking. Decisions as to how two things should match will be done with helpers such as those that already exist in Smart::Match.

... ~~ any(...)
[download]

Much more readable, much more flexible (fully extensible), and solves a number of problems (such as "When should X be considered a number, and when should it be considered a string?").

Along the same lines, the rules for when when uses smart-matching and when it doesn't are complicated. I suspect that will change.

Lexical $_ (currently used by given) apparently causes too much problems. For example, the following code doesn't work because first sets package variable $_, but the callback captured the lexical $_ declared by given.

given (...) {
   ...
   first { /.../ } ...
   ...
}
[download]

Rather than continuing to require callbacks to use our $_;, given will be changed to use package variable $_ instead of lexical $_ in 5.20.