Perl 6 is the only hope. And we must hope they get some production ready stuff out in a year or two.

If that's true, we should give up, because Perl 6 currently lacks answers even in spec form for "Concurrency, Web framework stuff, asynchronous IO, scientific programming, teaching courses etc", and of the three extant implementations, one has been effectively abandoned for several years, one has been abandoned by its primary author, and the other is in the middle of a rewrite away from a dead platform to another platform.

... and we have nothing new to offer for years now.

I don't know about that. I'd like to have function signatures and a MOP in the core, but the fact that Perl 5 gets Unicode right enough (okay, I'd like a more efficient way to load property tables, but encoding, normalization, and folding just work), that I can use Moose's MOP to make our code simpler and easier to use, and that our tests are efficient and effective lets us get a lot of work done that we'd struggle to do as quickly or correctly in another language.

I can't think of the last time we had a problem with Perl; our problems are "We have more work than people to do it", "Tuning databases for complex data sets is hard", "User data is messy", "Nobody has really solved deployment well yet", and "Our stakeholders don't really know what they want until we show them proofs of concept."

My point was not that we need stuff like Concurrency or an Asynchronous IO in the Perl 6 spec itself(As far as I know they are already a part of the Perl 6 spec). My point was that, for a framework to be written in Perl 6 to do <anything> no one currently considers it to be a stable, feature complete platform. Do we seriously expect somebody even at a Perl heavy shop like Amazon to take Perl 6 and build some API out of it?

Who then in real sense will use Perl 6 to solve some hard pressing problems developers/businesses face now?

You can say that from a certain semantic perspective production readiness is not the same for every one. But in such things, and things like stability- You measure stability by what is needed in the common cases and build it from there. And not for the lowest case.

Besides arguing about such things becomes irritating over a while. Its like what I wrote earlier about the beef steak. Will you at a restaurant accept, if raw uncooked meat is served and the waiter argues its ready for to be eaten from the perspective of a lion? Rather the definition steak as per you will be the most 'common cases' of steak(which is well cooked meat, added the recipe). You might still be OK if it is served without a little mint garnish. But you will at least expect to be cooked.

The need of the hour is to put all the energies in ensuring Rakudo can be spec complete, stable, with libraries and documentation ON ATLEAST ONE VM. Yet how many rewrites have we seen? How many different parallel half done attempts to run it on multiple platforms? How many abandoned projects? Pugs, Rakudo, Niecza, Ponie, Moe? .. and how many more?

As I said before, people might still accept the steak without garnishing. But expect it to be cooked. We need at least one spec complete, no-dead-on-arrival bugs, with libraries and documentation Perl 6 implementation. Frankly no one cares about running Perl 6 to two or more VM's in the very first production release. Every body understands such a demand is unrealistic. We can take all the time in the world to have run on multiple VM's once we do it right and complete on at least one VM. Python/Ruby have all done that. They have one solid complete thing, and then they have PyPy, IronPython etc.