From @Ovid

The following code prints "Int"​:
    multi f(Int $f where * < 20) {"Int" }    multi f(Int $f where * > 0)  { "greater" };     say f(3)
I'm told that "earlier wins", but sub resolution shouldn't be ambiguous. This is even worse with roles​:
    role R1 { multi method foo(Int $f where * > 0)  { say "R1" } }    role R2 { multi method foo(Int $f where * < 10) { say "R2" } };     class C does R1 does R2 {}; C.new.foo(3)
    # prints R2
Versus (note the role consumption order)​:
    role R1 { multi method foo(Int $f where * > 0)  { say "R1" } }    role R2 { multi method foo(Int $f where * < 10) { say "R2" } };     class C does R2 does R1 {}; C.new.foo(3)
    # prints R1
Now the order of role composition is important, but avoiding that is part of the reason roles were invented in the first place (http://scg.unibe.ch/archive/papers/Scha02cTraitsModel.pdf). It's a potential maintenance nightmare. Some developer, trying to make the code more readable, sorts the roles alphabetically and breaks the code via mysterious action at a distance.
This is perl6 version 2014.12 built on MoarVM version 2014.12

Best,Ovid--
IT consulting, training, international recruiting
       http://www.allaroundtheworld.fr/.
Buy my book! - http://bit.ly/beginning_perl
Live and work overseas - http://www.overseas-exile.com/