Your example in Python illustrates one of its major downfalls though. Certainly you can tell what's going on when you see

foo = (1, 2, 3)
bar = [1, 2, 3]
[download]

What happens after that when you use foo or bar? You have to know what it is, but not only what type of data it has, but how it was created.

This was my biggest stumbling block with Python: I couldn't use the variable names I wanted and I had to remember extra things about the variables I did see. Some people don't like sigils, but I love them. People keep trying to invent them with various notations and styles of variable naming.

The trick to any language is to think like the language and forget anything you think is "reasonable" or "makes sense". Instead of fitting the language into the way that you think, just take the language for the way it is.

For instance, the length() function operates on a scalar and is documented that way. The documentation is very clear on that. It doesn't matter to me what I think it should do as long as I know what it does do. Think like that and all sorts of problems disappear. You might still be offended by some missing symmetry, but life is messy.

As for your list cases, it's not that Perl allows those cases in particular, but that Perl allows these cases:

@array  = SCALAR;      # promotes to ( SCALAR );
... SCALAR, SCALAR ... # comma operator in scalar context
[download]

Once you have those general expressions, you can put them into larger expressions. It's actually more consistent to keep those because they are extensions of the same rules that allow other things (that you probably don't object to). Once you start adding special cases and exceptions, things get a lot more complicated and a lot harder to explain or remember.

They can't be syntax errors because they follow the rules. They might be candidates for warnings, however (just as an array slice with one element is legal, but generates a warning).