I'd actually consider it inconsistent behavior. Consider the following, which strongly resembles code I've read today:

sub genWhereString {
    my ($fields, $where, $orderby) = @_;
    my $query = "select " . join(", ", @$fields);
    $query .= " " . join(" and ", @$where) if $where;
    $query .= $orderby if $orderby;
    my $sth  = $dbh->prepare($query) || return $DBI::errstr;

    # et cetera
[download]

Obviously, the intent is that $where and $orderby CAN be undefined. If your change went through, would $where and $orderby become copies of $fields if they were undefined?

"Ah!" you say, "Simply change things so that a single-element, evaluated in list context, becomes an infinitely-long list of that element repeated."

Once you realize why that's not so good, you'll realize why the existing behavior makes sense. Yeah, this context stuff is hard to grasp at first. Once it sinks in, though, you'll wonder how other languages get by without it.

The idea of generating a special case for hash slices is a supremely bad idea. If you know enough to understand why @foo{@list} is still a hash even though it doesn't have the happy % in front of it, you're not too far from understanding that a scalar in list context might as well be a single element list.

Update: A one-element list has the same listishness as a ten-element list. It does not have as many values as the ten element list. That is the essential difference. In assignment #2 below, the scalar is evaluated in list context, which confers listishness upon it. However, the number of values it contains is only one.

In other words, when the interpreter encounters this behavior (assigning a shorter list of values to a longer list), how would your method handle the following cases?

1. my @a = (1 .. 10);
   my @b = (1 .. 3);
   @a = @b;
   [download]

   Obviously the correct behavior is that @a will contain three elements. If @b were somehow extended, would @a then be expected to contain qw ( 1 2 3 1 2 3 1 2 3 1 ) or qw( 1 2 3 3 3 3 3 3 3 3 )?

2. my @a = (1 .. 10);
   @a = (1 .. 5);
   [download]

   Again, the correct behavior is that @a will contain five values.

3. my @a = (1 .. 10);
   @a = 1;
   [download]

   Here is the clearest place where your technique should come into play. Would @a thus contain qw ( 1 1 1 1 1 1 1 1 1 1 )?

4. my @a = (1 .. 10);
   @a = some_sub_returning_one_or_more_results();
   [download]

   Suppose that subroutine performs a set operation, such as a union or intersection. There's no way of knowing, at compile time, how many results it will return. Suppose that for certain parameters, it returns one value. Should that be repeated to fill the available slots?
List assignment is list assignment. In my opinion, changing the fundamental behavior of Perl (and the difference between list and scalar context puts the fun in fundamental) because you don't yet understand it is a bad idea.

Comment on RE: RE: RE: RE: RE: Re: Possible pitfall with Slices Select or Download Code