D'oh... Yeah, you're right.

So, for the record, the evaluation order is in fact well-defined: It strictly evaluates higher-precedence operators first, before evaluating any operands of any less deeply nested part of the expression.

That's the source of my confusion: I intuitively expected Perl to only use the operator precedence information to implicitly "add parenthesis" for disambiguation, but then evaluate the expression left-to-right, only recursing into nested sub-expression once they are encountered.

That's two conceptually very different ways of defining evaluation order, but easy to miss because in practice it probably never makes a difference except in special cases involving += and friends.

Well, almost never... :) Here's a demonstration of the evaluation order using tied scalars that report when they're being accessed:

use warnings;
use strict;

package LoggingScalar {
  require Tie::Scalar;
  our @ISA = qw(Tie::StdScalar);
  
  sub FETCH { print "fetched: ".(${shift()} // '<undef>')."\n" }
}

tie my $x, 'LoggingScalar';
tie my $y, 'LoggingScalar';
tie my $z, 'LoggingScalar';
($x, $y, $z) = qw(x y z);

print "---\n";
my @a = ($x, $y . '!', $z);
[download]

...which outputs:

---
fetched: y
fetched: x
fetched: z
[download]

As for the mentioned perlop paragraph re. "undefined behavior", I suppose that refers to what Eily says here.