The anonymonk above is correct. Perl's lexer doesn't expect an operator in this position (although it can handle "unexpected" operators). And this is done in the lexer, not the parser. Specifically, in Perl_yylex (toke.c):

     case '/':    /* may be division, defined-or, or pattern */
         if ((PL_expect == XOPERATOR || PL_expect == XTERMORDORDOR) &&
+ s[1] == '/') {
            ...
            AOPERATOR(DORDOR);
        }
        else if (PL_expect == XOPERATOR) {
            ...
            Mop(OP_DIVIDE);
        }
        else {
            ...
            s = scan_pat(s,OP_MATCH);
        }
[download]

I'm no expert in how the lexer works but implementing parsing on such heuristics is a fragile thing.

Oh yes, Perl's lexer is fascinating :) I'm not an expert either, life is too short...

For example, you said that the concat op works...

    case '.':
        ...
        if (PL_expect == XOPERATOR || !isDIGIT(s[1])) {
            ...
            Aop(OP_CONCAT)
[download]

So, if the lexer doesn't expect an operator, it decides based on whether the next character is a digit... Let's see:

$ perl -MO=Deparse -e 'sub foo(&) {}; foo { "foo" } . 5'
sub foo (&) {
    
}
foo(sub {
    'foo';
}
) . 5;
-e syntax OK

$ perl -MO=Deparse -e 'sub foo(&) {}; foo { "foo" } .5'
Too many arguments for main::foo at -e line 1, at EOF
-e had compilation errors.
sub foo (&) {
    
}
&foo(sub {
    'foo';
}
, 0.5);
[download]

but:

$ perl -E 'say 1 .5'
15
[download]

because here it does expect an operator.

So, yeah... Just don't think too much about it :)

Hopefully this can be fixed in the future.

That would require fixing the grammar of the Perl 5 programming language; the major version surely should be incremented then and the backwards-incompatible result should be called Perl 6... oh wait...