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.