This is an idea that sounds good in principle, and that is destined to turn out not so good. Problems:

• Additional complexity introduced to the Perl code base will undoubtedly lead to a new round of bug-fixes.
• A new syntax that will begin to creep into modules and new code that push forward the minimum Perl version without significant benefit.
• A new set of special cases. I can see it now in Intermediate Perl: "You may omit the -> operator between subscripts, but not between a reference and its flattener
• If @{ $aref->[1] } is ugly, is $aref->[1]->@* prettier? At least the first seems mostly symmetrical, and visually distinctive. And it has the benefit of putting the most important thing first; we're generating a list. Beauty is in the eye of the beholder, but you would have to be an alien to find more beauty in the new construct than in the symmetry of the old one. Why do we need to put the most important part at the end? Discomforting, it is.
• It doesn't make simple things easy, or hard things possible. And it really doesn't make impossible things possible. The barrier to entry into Perl syntax really ought to be, "Does it make hard things possible? Does it at least make simple things easier?"

TIMTOWTDI doesn't mean we need to add every imaginable syntactic alternative.

Extended bracketed character classes.... now that is a feature that made hard things possible, and well worth the round of bug patching it initiated. In some cases, it may even be worth bumping up the minimum Perl version number of an application or module. // and //= were also slam dunks for making simple things easy and a little more efficient. say..., ok, great for perl -E one-liners, and in code that already needs a sufficiently new version of Perl for other reasons. fc: Absolutely; it makes hard things possible. s///r, for sure. It makes simple things easy.