The first example combines autoloading with typeglobs in a way that the Camel book doesn't even think about addressing.

But the Camel discusses autoloading, and it discusses typeglobs. Sure, it doesn't discuss combining them, but it doesn't discuss combining autoloading and splicing either. Does that mean the use of splice inside an autoload routine is "undefined behaviour"? If not, then what determines which undiscussed combination of discussed techniques is "undefined" behaviour, and what isn't?

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

Bzzzt! Thank you for playing.

From the 5.005_03 perlfunc manual page:

values HASH
        Returns a list consisting of all the values of the named hash.
        (In a scalar context, returns the number of values.)  The
        values are returned in an apparently random order.  The actual
        random order is subject to change in future versions of perl,
        but it is guaranteed to be the same order as either the keys()
        or each() function would produce on the same (unmodified) hash.
 
        Note that you cannot modify the values of a hash this way,
        because the returned list is just a copy.  You need to use a
        hash slice for that, since it's lvaluable in a way that
        values() is not.
 
            for (values %hash)      { s/foo/bar/g }   # FAILS!
            for (@hash{keys %hash}) { s/foo/bar/g }   # ok
 
        As a side effect, calling values() resets the HASH's internal
        iterator.  See also keys(), each(), and sort().

(Emphasis mine). But from the 5.8.x manual:

values HASH
        Returns a list consisting of all the values of the named hash.
        (In a scalar context, returns the number of values.)
 
        The values are returned in an apparently random order.  The
        actual random order is subject to change in future versions of
        perl, but it is guaranteed to be the same order as either the
        "keys" or "each" function would produce on the same (unmodi-
        fied) hash.  Since Perl 5.8.1 the ordering is different even
        between different runs of Perl for security reasons (see "Algo-
        rithmic Complexity Attacks" in perlsec).

        As a side effect, calling values() resets the HASH's internal
        iterator, see "each". (In particular, calling values() in void
        context resets the iterator with no other overhead.)
 
        Note that the values are not copied, which means modifying them
        will modify the contents of the hash:
 
            for (values %hash)      { s/foo/bar/g }   # modifies %hash values
            for (@hash{keys %hash}) { s/foo/bar/g }   # same
        
        See also "keys", "each", and "sort".

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.

Did you actually look at the code? Here's it again:

print 80.101.114.108;
[download]

No bare words in this piece of code, and no version of Perl issues a warning.

$ perl5.00503 -wle 'print $]; print 80.101.114.108'
5.00503
80.101114.108
$  perl5.8.6 -wle 'print $]; print 80.101.114.108'
5.008006
Perl
[download]

See, no warnings. And for your information, in 5.005_03, 80.101.114.108 isn't a bareword. It's the concatenation of two floating point numbers. In 5.8.6, it's a v-string (which as shown are in another thread, are on their way out, so the program above is probably not going to print "Perl" in 5.10 or 5.12).