Excellent question. I think a big part of the customer story is eventually getting a standardized object model like Corinna into the core language. I do know a lot of objections to Perl have come from the bare-bones built-in objects and the dozen or so ways to build on those using CPAN modules. Getting signatures in rather than the older function prototypes is another. I don't know that there is a unified vision for what future Perl will be yet, other than something that surprises people coming from other languages a lot less yet remains Perl.
Thanks for the comment. I'd say that sounds like a good start. But making it easier for people to switch to Perl is still different than giving people reasons to switch to Perl.
For example, at my current job we picked Python as our default language because a) it's a solid language, and b) since we're doing exploratory ML work, Python's dominance in the ML and data science worlds means good tools and a strong community. Previously I switched to Ruby because a) it's a solid language, and b) Rails made it really easy to build the sort of web stuff we were building at the time. Or when I was building a mobile app I went with Dart and Flutter because it was the only decent-looking platform that would let me do cross-platform development as a solo developer, and it seemed like Google was serious about making it happen.
So I think Perl has to answer the question: whose problems are we going to solve better than anybody else? From what I've seen over the years, it looks like the answer is "people still using Perl". Which is not a terrible answer; it serves for the COBOL and Fortran communities.
Well, Perl is still a solid and improved replacement for sed, awk, and shell. PSGI puts it about on par with other platforms for persistent web apps with Mojolicious, Catalyst, and Dancer all solid frameworks for that.
It's reasonably performant. It has true multithreading with no GIL and handles multi-process programming well too. For several years the regex engine has been iterative except for places like backtracking that pretty much need to still be recursive. It's among the fastest language systems that do reflection and offer true closures and lambdas. It used to be faster than a whole lot of other languages, but lots of other have made more progress on that front. Deprecating some features and being willing to break compatibility will allow more optimizations in the compiler and opcode interpreter.
It does portable deployments really well with perlbrew. Or if you want just an easily deployable app, there's Carton. Strawberry Perl works on Windows pretty identically to how perl works on Linux or BSD. Perl runs fine on Android, although it can be a little memory-heavy for constrained devices.
One of the killer features for me is CPAN and in particular metacpan, cpanm, and CPANTesters. Having the code, docs, star ratings, and a matric of which versions are passing all test on which platform all in one place with a good search engine in front of it is really handy. NPM came a lot later for example and still doesn't have things like version pinning and local re-vendoring worked out.
As for what's going to grab a lot of new developers or lead a lot of established developers away from their current preferred languages, I really don't know. If I was starting today and looking for one primary language that was fast to develop, reasonably fast in production, full-featured as a language, and had great library support I might go with Julia, OCaml, F#, Common Lisp, Ruby, JS/Node, Racket, or Scala Native. Maybe even Pike or Lua (Lua since its FFI is so strong any C library is basically also a Lua library).
I'm someone who's been using Perl as one of my primary languages since the 1990s. It's one of my top 4 or 5 languages, and for whole classes of problems it's what I reach for first - at least for prototyping something out. I really like Raku, which has great performance in spots but is still very slow in parts of the language. That language's killer app so far is parsers, by a long shot. Since I'm still using Perl for many things, a cleaner, faster, less crufty Perl would be a great thing. I also think since most of Perl's strengths are still fairly well known but some of the more arcane things like output formats, tied variables in the core, and the core object syntax being kind of raw and under-opinioned are considered too crufty to overlook that cleaning those up might be enough to grab the attention of people who might be on the fence.
