The anecdote goes that, during a meeting of Perl 5 Porters at The Perl Conference in 2000, Jon Orwant seized a moment to start throwing coffee mugs at a wall. (Jon leaves little to chance.) With the dot-com bubble bursting, fierce infighting on the p5p mailing list, and a language with lots of possibility but no galvanizing principle, Perl seemed in danger of stagnation.
Most people reading this know the punchline: a dramatic rethinking of what Perl is and could be coupled with a backwards-incompatible rewrite of the internals, intended to come out in sometime around the end of 2002. (Time will tell if a usable P6 ever appears.)
Legend has it that announcing "the next major version of the Perl programming language" announcement was as much about revitalizing the Perl community itself as it was about any technical achievement. Certainly Larry's desire to see a kindler, gentler, less fractious community has taken quite some time—but things have improved.
From the technical side, I could list improvements in release process, testing, documentation, usability, performance, library availability, and syntax, but that approaches the question from the wrong angle.
The most important question in July 2000 about Perl's future is still the most important question in July 2012 about Perl's future. That question is this:
Is it reasonable to write new code in Perl right now?
The answer depends on the domain and your preferences and the dynamics of your coauthors and many other factors. You could list a dozen, and they might match the dozen I could list. The specific answer and the reasoning behind that answer matters much less than the gestalt of that answer. Who is answering that question? Why?
To the extent that technical concerns (stability of the language, future maintenance possibilities, library availability, presence or absence of bugs) exist, the Perl community knows how to manage those concerns. We've done a credible job in many areas, and we've even blazed new trails in others. (We're still a tribe of syncretic polyglots though: for every mod_perl which gives way to Plack, a PPI spawns a Perl::Critic and an ithreads is better than a GIL but otherwise somewhat unspectacular. For every Moose, someone says "Don't Tcl and Lua all require you to do something similar?")
To the extent that human factors (availability of developers, credibility of developers, cost of developers, and whether that fixie-riding hipster would deign to give up his precious for a language with a working lexical model and an actual library system) exist, we haven't solved the problem.
The problem is, as usual, one of communication and visibility.
It's not that Perl is or isn't a credible language for writing important applications. (It is, and it's an order of magnitude better in 2012 than it was in 2000 as I see it.) It's that the perception of Perl is more important to people outside the Perl community than any technical factors.
Certainly the inability of Rakudo's developers to release anything that much of anyone cares about has hurt Perl—although deconstructing the Osborne myth is interesting. It's not the only reason Perl appears to have stagnated, but splitting the community and offering a hazy potential future for more than a decade didn't help, to put it lightly.
Perl circa 2000 struggled with the success of Perl 4, the ubiquity of Perl on Unix systems, and the CGI model of writing web applications. This meant a lot of people had seen a lot of awful chewing-gum-and-baling-wire monolithic code written and barely maintained. The good news is that a decade of focusing on things like comprehensive testing, coding standards, infrastructure, and a relentless sense of improvement to design and implementation have given people who know what they're doing a fine set of master tools to craft beautiful things.
(That's one reason I like the term "Modern Perl" and others like "Enlightened Perl" or talk about "The Perl Renaissance". If I wrote the same code in 2012 that I wrote in 2000, I'd be a terrible programmer.)
The better news is that even though a novice likely won't understand what a parametric role is let alone when to use it or why, he or she can still get stuff done with minimal ceremony and no fuss. (Sure, the resulting code will be awful, but at least one aspect of the programming world can be honest about novice code: it's awful. It's never not going to be awful, even if you teach them SML or Eiffel or Ada or Python. People who don't know how to program well won't program well. Embrace the tautology.)
If I were handed Moose, Catalyst, DBIx::Class, HTML::FormHandler, Dist::Zilla, Plack, and a few other tools in 2000, I would have deleted thousands of lines of code. Immediately. We have amazing technical features. We have a vibrant community. (Look at attendance rates at YAPC and growth rates of CPAN. We still have a growing community.)
These are all good things, but the coffee mug question and the answers are still relevant and important and vital.
(Note carefully: the question says nothing about "maintaining existing code". That concern is far different and the answer from a business perspective necessarily must consider things like opportunity and sunk costs.)
The answer isn't obvious. The answer isn't easy. (The answer isn't "Can someone throw some rounded corners and drop shadows and Lobster fonts on Perl web properties?") Then again, the answer isn't "Fork and rename" or "Buy an ad in an IT weekly rag" either. Part of the answer may be "Continue to improve the core and out-evolve everything else in any ecological niche possible, but the biggest part of the answer is this:
Build credible new things. Brag about them. Repeat.