There are at least two ways to get where you want based on the STD grammar. You could override (or wrap) the EXPR method to do more than simple operator precedence, but then you'd have to explain to your users how that works in a way that will make sense to them. Operator precedence has the great advantage of being easily understood by most people.

Or you could just handle it the way STD handles the existing conditional operator. STD is a hybrid grammar after all; you get to use either operator precedence or top-down parsing as you see fit. In particular, the operator precedence grammar knows how to stop when it sees something "too loose", so we can take advantage of that by pretending the ternary operator is really a binary operator with a complicated middle. Here's the STD rule for the conditional operator:

token infix:sym<?? !!> ( --> Conditional) {
    '??'
    <EXPR(%conditional)>
    [ '!!' ||
        [
        || <?before '='> <panic: Assignment not allowed within ??!!>
        || <?before '::'> <panic: Please use !! rather than ::>
        || <?before <infix>>    # Note: a tight infix would have parse
+d right
            <panic: Precedence too loose within ??!!; use ??()!! inste
+ad >
        || <panic: Found ?? but no !!; possible precedence problem>
        ]
    ]
    {*}                                                         #= ?? 
+!!
}
[download]

As you can see, most of that rule is just trying to give the poor, misguided user some really good feedback on what went wrong. This is something that is relatively easy to do in a top-down setting, but rather difficult with a bottom-up parser. But stripping away the messages and the reduction apparatus, we find the rule is essentially just:

token infix:sym<?? !!> {
    '??'
    <EXPR(%conditional)>
    '!!'
}
[download]

To the outer parser, that's just one infix operator, but syntactically the infix's "token" just happens to contain an expression in the middle. Limiting that inner expression to the precedence of the conditional allows us to catch brainos like:

$a == 1 ?? $b = 2 !! $b = 3;
[download]

Now, you could certainly try something similar to parse the rule you proposed:

EXPR INFIX EXPR LEFT_DELIM STRING RIGHT_DELIM
[download]

However, your rule has a couple of difficulties from a Perlish perspective. First, if you try to write it as an infix operator, you'll end up parsing all the rest of the rule as the infix, and have a null right argument. Syntactically it's really a postfix because you'll be expecting an operator after it rather than a term. But the postfix category in standard Perl requires an absence of whitespace before it, so you'd really rather classify it as infix if you want whitespace before it.

So then perhaps you say, we'll just parse the "INFIX EXPR" as the infix operator and let the ordinary operator precedence parser pick up at the delimited string, since it would be expecting a term anyway. But then you have to worry about picking up an accidental operator after that term as part of the final term, when you really wanted to force the final term to be just the delimited string.

Which brings us to another difficulty, which is that if you're going to call <EXPR(...)> as part of your token rule, you have to tell it where to stop, and where you want it to stop is not a standard expression terminator. The basic underlying problem is that your rule is trying to have two terms in a row, which is just always going to be a bad idea in Perl. It could be forced to work here, but we'd somehow have to tell that inner EXPR its complete set of possible terminators in order to suppress the "two terms in a row" error message that you'd get by default.

I'm not saying this is always a bad idea. We essentially do the same thing to force the syntax of

for 1..10 { ... }
[download]

to allow two terms in a row (the 10 and the block following it). But we can get away with that only because 1) pragmatically it's a very high-level and important construct, and 2), syntactically we have no infix operators starting with the { character, and 3) we require whitespace to distinguish infix from postfix operators, which means it doesn't really matter that we have a postfix operator that starts with the { character. And of course the most important is 4), we never, ever allow two terms in a row to imply an infix operator between them.

So the short answer is: "Yes, you can do that, but you don't really want to." :-)