I don't mean to be argumentative, but I am as yet unconvinced that the rules I gave are unworkable in practice.
To begin on a positive/agreeable note... you say:
What looks like a list to a casual reader is often not the list that Perl sees
I agree completely. And this problem is exacerbated by the lack of a clear definition of what is a LIST in the Perl documentation.
Many people might say that 1, 2, 3 is a list...
The rule I gave is a rule for evaluating a LIST in scalar context. It is not a rule for determining what part of a statement is a LIST or what the elements of the LIST are.
Other rules are required to determine what is a LIST and your example illustrates some of the complexity of doing so. It does not convince me that the rule I gave is unworkable in practice.
While some statements are difficult to parse, others are simple. The use of optional parentheses can simplify the task which otherwise, as you point out, requires an intimate knowledge of precedence and other rules.
The fact that some statements are difficult to parse does not mean that there is no such thing as a LIST in scalar context.
...they get optimized away...
The rule I gave was a rule describing the semantics of Perl, not the algorithms of perl. That perl can and does use optimized algorithms for executing Perl programs is a good thing as long as it remains consistent with the syntax and semantics of Perl. I don't agree that an optimization in perl for some particular case makes the rule I gave unworkable in practice.
(Besides that, this proves that the general rule "A list in scalar context evaluates to its final element" is wrong, too.)
I don't understand how it proves this. Can you explain further?
The value of any expression evaluated in void context is discarded. This does not invalidate a rule defining what the value of the expression is. That perl is optimized to skip steps that have no side effects when evaluating an expression in void context does not, in my opinion, have any bearing on what the value of a LIST in scalar context is.
I am talking about the semantics of Perl and you seem to be talking about the operation of perl. It is natural then that we should have different opinions about what is or isn't and what happens.
Update: fixed a typo in the last sentence