This is still a problem on the JVM backend. I tried a second time to find the
underlying problem and arrived at the same conclusion: There seems to be
something wrong in 'analyze_dispatch'. When running the given code
multi foo ($) {"right" }; multi foo ($ is rw) {"wrong"}; say foo "42"
'analyze_dispatch' returns the second sub with $MD_CT_DECIDED. This (wrong)
result is taken for real on the JVM backend, whereas on MoarVM it isn't really
used in this case -- cmp.
https://github.com/rakudo/rakudo/blob/4df02facd0/src/Perl6/Optimizer.nqp#L3109-L3113
I didn't grasp all the details, but the problem might be related to the fact
that 'sort_dispatchees_internal' returns an array with five results: [2nd_sub,
Mu, 1st_sub, Mu, Mu]. The second sub comes first, because it is narrower than
the first sub. The Mu at index 1 seems to indicate the end of a tied group.
This leads to 'analyze_dispatch' looking at the second sub first, not detecting
a problem there (due to the missing check for a literal being passed in) and
returning this sub after seeing the Mu.
I still think my patch from 2017 makes sense. With this patch,
'analyze_dispatch' rejects the second sub, notices that it didn't analyze all
candidates and returns $MD_CT_NOT_SURE. But it would be even better if
'analyze_dispatch' dispatches to the first sub with $MD_CT_DECIDED.
