It's got nothing to do with operand evaluation order.

Who said anything about operand evaluation order? (How could there be an operand evaluation order for a unary operator.)

I'll come back to this.

It has to do with pre-increment returning lvalues.

$i = 0; ++$i = 'fred';;
Can't modify preincrement (++) in scalar assignment
[download]

So, not an lvalue.

is more or less equivalent to ... alias

Ah! That well know Perl keyword 'alias'....

It's got nothing to do with operand evaluation order.

Hm. "It" has everything to do with the fact that the evaluation order of sub-expressions is unspecified.

Where "it" is the contradictory and useless behaviour, observed by the OP, and repeated in my post.

Because, if were specified, then the implementation would not be able to get away with producing those totally illogical, useless results, for those unwise or unknowing enough to try and use, what could be a useful behaviour.

Your attempts to explain how the implementation produces these useless results from this unspecified and therefore deprecated code, does naught to detract from the reason why it has been possible to enshrine this broken behaviour in the implementation.

The fact that f( ++$n, ++$n ) passes an alias to $n, rather than the value resulting from the preincrement, is just another broken behaviour. It is equivalent to C allowing:

#include <stdio.h>

void f( int *a, int *b ) {
    printf( "a: %d, b: %d \n", *a, *b );
    *a = 1;
    *b = 2;
}

int main( int argc, char ** argv ) {
    int x = 0;
    f( &( ++x ), &( ++x ) );
    return 0;
}
[download]

Which it doesn't:

junk.c
junk.c(11) : error C2102: '&' requires l-value
junk.c(11) : error C2102: '&' requires l-value
junk.c(11) : error C2198: 'f' : too few arguments for call
[download]