There is a real issue in breaking existing programs. The perl5 porters weigh heavily in backward compatibility. You don't want all your existing scripts to die because one of the new features makes your existing code die. E.g. let me assume you have a functuntion called say, not entirely unlikely. By declaring to use the new features the current perl offers you, you now have to think everytime you see that funtion if that is the sub from you or the one that is enabled by your request to get all new and shiny whatever.

For short scripts, one-liners and scripts that only use core-stuff and very basic things, it might not matter, but then you'd already be happy with just stating the obvious use strict;. It is a choice the porters made: enabling new shiny features in a rather easy way contra breaking existing code by just enabling new syntax.

An additional opportunity is now handed to you to test your code without breaking it. Testing is good. I've been in QA quite a while now, and I must say that perl is one of the few languages where testing is one of the first subjects mentioned when they say where a language is good in. Funny I never hear that for python, and I hear people praise junit, but not using it as much as they should for java.

Personally I resent some "features" being enable by default in even low-level languages like C. GNU started enabling // comments long before C99 made this a standard. Any idea how many programs now cannot be compiled on machines that have VERY EXPENSIVE ANSI-C compilers that comply to C89? That causes hate and grief. I'm glad not to see that in perl, and if shit like that happens, I get an opportunity to turn it off (most of the time) and I get warned well in advance that a change will happen.

"I don't see anything like this in other languages."

I can't use C++ range-based for loops, lambda expression syntax, variadic templates, uniform initialization, move semantics, or any other C++11 feature with my GNU compiler unless I specify -std=c++11 to the compiler. The reason, I suppose, is to avoid the potential for silently breaking old code by changes in keywords, syntax, and semantics. One might say that it would be better for the GNU compiler to default to C++11, and allow a command line switch to revert to older syntax/semantics. But then all old code would have to have its makefile updated, or it would run the risk of becoming broken.

This is the same principle at work with not, by default, enabling features to Perl that introduce newer keywords or semantics. Just because you haven't seen it in other languages doesn't mean it doesn't exist in other languages, and doesn't disqualify it as a "least dangerous" way to upgrade while avoiding damaging legacy code.

OK, I should have said the languages I've looked into (Ruby, Python, Erlang, Clojure, Elixir, Javascript, Scheme, Lisp) get by without version strings specified in the code.

The Python 2 to Python 3 migration has been incredibly painful, and there are still a huge number of people on Python 2. Ditto for Ruby 1.8 to 1.9.

Javascript has had a nightmarish compatibility and upgrade story.

Scheme and Erlang are fairly rigidly specified.

Clojure is young enough that breakage is treated as expected between versions.

Lisp is a whole family of languages - but if you mean Common Lisp, it's been extensively tied to an essentially fixed spec for a very, very long time.

for(split(" ","tsuJ rehtonA lreP rekcaH")){print reverse . " "}print "\b.\n";

> I don't see anything like this in other languages.

I do. To use C99 data-types in code that I compile with my favourite complier* I need to provide the -c99 flag on the command line.

* spelling deliberate. I use it because it's very picky about correctness and standards compliance.