Example?

*blink*

Are you suggesting you have never heard of programs broken because of an upgrade of Perl? Where do you live? Mars?

Here's a goodie, which both shows the lack of standards, and the breakage of upgrades. Look at the following program:

sub AUTOLOAD {print $AUTOLOAD}
*foo = bar;
foo ();
[download]

Three questions:
1. The program should print:
   1. main::foo
   2. main::bar
   3. Something else
2. perl5.005_03 prints:
   1. main::foo
   2. main::bar
   3. Something else
3. perl5.6.0 prints:
   1. main::foo
   2. main::bar
   3. Something else
Without actually running the program, but with consultation of all the documentation that comes with Perl, and any version of the Camel you like, could you answer all questions correctly?

Here's another program:

my %hash = (foo => 'bar');
chop for values %hash;
print values %hash, "\n";
[download]

The program prints ba when run with 5.8.6, but it prints bar when run with 5.005_03. And that wasn't a bug fix.

Third program:

print 80.101.114.108;
[download]

Prints 80.101114.108 in 5.005_03 and earlier, but prints Perl from 5.6.0 onwards. You might say that noone writes 80.101.114.108 in normal program, and that's true. But evalled computer generated code can.

I'm not saying these examples are huge problems, and it takes a lot resources to fix. But breakage does happen. Over and over and over again. And it does take resources to find the breakage. And for large organisations running a myriad of programs, that is a problem.

You're making my point for me. All of your examples (ab)use the same sorts of nooks and crannies of the language that the OP readily admits have to be avoided by C programmers in order to avoid breakage.

The first example combines autoloading with typeglobs in a way that the Camel book doesn't even think about addressing. As you point out yourself, the questions you ask cannot be answered from the documentation and the Camel, which implies that the code represents undefined behavior. How is this any different from the undefined behavior in C, if you program outside the ANSI spec by targetting a specific compiler and OS?

The second example plays games with aliasing, again in an obscure and AFAIK undocumented corner of the language.

The third example tries to abuse barewords, which have been heavily deprecated since the Perl4 days and have been throwing warnings since 5.003 at least. Anybody who writes something like that in production code deserves whatever he gets, and it is trivial to find similar examples of nonstandard code breaking in C due to something as minor as compiling for a differently-endian hardware, to say nothing of switching compilers.

If you write your code based on the information in the 2nd edition Camel book, it will work in all Perl versions from 5.003 forward; if there is even a single counterexample to this, I am not aware of it. (Feel free to point it out...) Needing to avoid the undocumented nooks and crannies is no worse in Perl than it is in C. When issues like endianness are considered, I maintain my previous assertion: Perl is more standardized than ANSI C.

---

"In adjectives, with the addition of inflectional endings, a changeable long vowel (Qamets or Tsere) in an open, propretonic syllable will reduce to Vocal Shewa. This type of change occurs when the open, pretonic syllable of the masculine singular adjective becomes propretonic with the addition of inflectional endings."  — Pratico & Van Pelt, BBHG, p68

Sorry, but I think you're using the wrong Perls then. Between every major version of Perl (the 5.5.x train, the 5.6.x train, the 5.8.x train ("stable") and the 5.9.x / 5.10.x train ("blead")), new features get introduced, 5.8 introduced PerlIO and Unicode in a wide range, 5.10 will have new stuff I don't know. If you need to use certain features and rely on certain features that are not commonly used, don't move your program to a new major Perl version before thouroughly testing it.

Of course, if you don't supply the version of Perl your script is used with, you will need to test your script against all versions of Perl, but at least the future versions of Perl go through prereleases ("Release Candidates") before becoming public, and so you have some chance of getting an early warning by testing your program against bleadperl.