It's action-at-a-distance in that given the statement my $foo = split( /;/, $bar ); you haven't mentioned @_ at all and yet @_ will be modified. I can see the case for an analogy with $_, but in the cases where $_ is used as a default argument (and @_ is used similarly only for push pop shift unshift that I can recall off hand) you don't specify any argument and $_ (or @_) is what's mucked with. In the example I give @_ is never mentioned but there is an explicit argument passed ($bar). That's what I mean by action-at-a-distance; I mentioned another variable explicitly and yet @_ is altered implicitly.

Again, I don't think it's really an error in general since it works fine save for this corner case. But I definitely wouldn't blink twice at a documentation patch adding an explicit warning about this corner case (again analogous to the warning against modifying the variable in a for loop in perlsyn). While the for case isn't destructive per se, the behavior is undefined for both and should be avoided because you can't depend on what it's going to do (just as you can't depend on what splitting in scalar context from an element of @_ is going to do). And on the third hand I also wouldn't think it worthless to maybe forward your test case on to p5p and see if anyone there thinks the bad behavior is worth looking deeper in.

I still think it's mostly a "Doctor! Doctor! It hurts when I do this!"/"Well, don't do that." situation. Don't exercise the corner case and there's no problems.

Update: minor edit and added note about running past p5p.