I have my doubts as to whether all of these bugs have actually been found and fixed in Perl. (The result "0" is simply wrong, whether a flawed optimizer did it or not.) There are many functions in Perl, like chomp, which were plainly designed to be used “in one ‘right’ way,” and which in however-many releases have never worked properly in any other way. If the function (like chomp) is designed to “do something to” its right-hand side, i.e. treating the argument as a so-called “lvalue,” you should never in Perl use that same variable as an lvalue, as you did in this case by using an assignment statement. It’s Forrest Gump’s box of chocolates: you never know what you’re gonna get.
Perl’s lineage and inspiration definitely draws from awk, and it still shows, especially in its use of perlvars, particularly "$_". There’s a whole lot of “implied context” going on here, and from a pure language-design standpoint that means ambiguity, and that means trouble. For example, consider the following three Perl one-liners, shown with their output on Perl 5.19:
$ perl -e '$_="foo\n"; chomp; print "$_\n";'
$ perl -e '$_="foo\n"; $_=chomp; print "$_\n";'
$ perl -e '$_="foo\n"; $_=chomp($_); print "$_\n";'
# (tpyo correctud)
$ perl -e 'my $foo = "foo\n"; $foo = chomp($foo); print "$foo\n";'
The first case is what is used 99% of the time, because “the function is an English verb.” Effectively, it is an imperative statement. You want to “chomp” a string, and it does. If you use the implied-variable "$_" it also produces the documented result, even though nobody actually does that. If you use your own variable, it does not. Given that you probably don’t have the latest Perl installed on your machine and probably can’t change it, you have to code-around bugs like these. If the function is a verb, use it as a verb only.