It isn't a list nor an array in scalar context that your example is making use of. It is a list assignment (in scalar context).

A list assignment in scalar context returns the number of items in the right-hand list.

And, in your example, 'x' =~ m/(.)(.)/, in a list context, returns an empty list, not a list of two 'undef's. An empty list (on the right-hand side of the list assignment) contains zero items so the assignment in scalar context returns 0, which is one of the documented false values.

But there is a kernel of truth hidden behind your mistakes.

There have been some exceptions (as near as I can remember, on an inconsistent basis) to the rule about what a list assignment returns in scalar context. Those exceptions were meant to handle cases very similar to what you described.

sub undefs {
    my( $count ) = @_;
    return ( undef ) x $count;
}

if( my( $x, $y ) = undefs(2) ) {
    print "true\n";
} else {
    print "false\n";
}
[download]

In some versions of Perl, that code would print "false". In the relatively modern Perl I had handy, it prints "true".

I even recall having a very short on-line conversation with Larry years ago about what I considered to be bugs such as ( undef, undef )[0] being an empty list instead of being a list containing a single 'undef' and he was worried about breaking the fact that the above code was supposed to print "false". I argued that that wasn't a feature worth keeping.

But I didn't follow-up to see what decisions were made back then. And, just now, I didn't test the current behavior except minimally. I think there was at least one thread about this stuff on PerlMonks around the time Larry and I talked, but I haven't looked for it. It might've just been in the chatterbox.