This is a good "patch the holes" plan, but I think it needs to be followed up in short order by some deeper thinking. And some very painfully honest thinking.
Paul Graham, whom some of you may have heard of, once wrote an essay about "What Languages Fix": http://paulgraham.com/fix.html
I think of it a bit differently, which is that languages have a thesis. (Not quite the same but a lot of overlap.) Paul writes that what Perl fixes is "Shell scripts/awk/sed are not enough like programming languages." I would personally rephrase it to something like "There isn't(/wasn't) a language dedicated enough to Getting It Done."
If you put yourself in the context of the time, this was absolutely true. Most languages for getting things done involved a lot of drama and boilerplate. Popular languages of the day would require you to implement your own hash table for a quick script, if you didn't have one on hand. Libraries for that existed of course, but the Internet wasn't really up and running the way it is now yet, and things were hard to find. Perl came in and provided a great Get It Done languages.
However, landscapes evolve over time and so do language theses. C++ is a great example of something that has changed, going from "C should have great support for object orientation" to something more like "C++ should be the choice for programmers who want zero-cost abstractions". Part of the reason for that change is that the former thesis is no longer a compelling one, on the grounds that "great object orientation support" is now simply table stakes for that sort of language. C++ could not drive forward on that thesis in 2021.
That is also Perl's real problem right now. It lacks a thesis. It has very narrow advantages in text munging still, but for almost anything else, I now have an abundance of languages that "get it done" just as well or better. For context, I've got about 15 years of Perl being my primary language under my belt, so that means something; it's not a secondary or tertiary language for me, and I still have plenty of choices to reach for. (Heck, I've even come to prefer Go for JSON munging quite a lot of the time, because with the right tooling it's really easy to parse JSON straight into objects that I can call methods on meaningfully, which is actually more convenient and useful to me than presenting me with a generic hashtable/array representation that I then have to write a lot of code to crawl over from the "outside".) The world has moved on, and Perl's problem isn't necessarily that it lost but that it won. It has successfully convinced the world that Getting It Done doesn't need to come with all the drama and paperwork and complexity of its late 1990s peers. But that means that just like C++ won and it couldn't continue operating on its "good OO" thesis, Perl needs a new thesis.
Moreover, it's going to have to be brutally honest in the selection of that thesis, because a lot of the obvious ones are already covered by Python, and trying to chase Python on its own turf is going to be a losing game. Perl 6/Raku also has its own thesis, which is now also essentially unavailable to Perl 5. Unfortunately, choosing a thesis successfully isn't necessarily about what the Perl team "wants" so much as where there is space in the programming language market, and in the intervening, gosh, decade or so that Perl 5 has been floating along without a thesis, a lot of the easy or obvious answers have been fairly well covered by other languages.
One thesis option is "Old perl code should degrade gracefully", which is the "declare victory and walk off into the sunset" option. To be honest, it's one that should be seriously considered. I think graceful retirement is a test a lot of language committees fail. Here I'd look for improved refactoring tools to help automatically translate old code into better code to modern standards and other such things being the standard, for instance.
But if the Perl 5/7 team wants a different thesis, it's something I think they need to decide consciously. I don't have a suggestion. But I can offer this word of hope; the space of possible theses is really quite large. The point of view where it looks like every possible language exists already is a point of view that is too narrowly stuck in the details of today. With just a bit of change in perspective, there's a lot of untapped fields.
Tempering that hope a bit, Perl's new thesis really needs to be something that Perl's existing code and community brings something powerful to. If you come up with a possible thesis, but look at it honestly and say "That's probably something better done with a brand new language entirely", it's probably not a functional thesis for Perl. And this does cut the space back somewhat. But some persistent thought may still find something interesting.
Personally, I'd also be looking carefully and honestly at what Perl is still doing and consider shedding old use cases/theses. For example, while Python is not experiencing a popularity crisis, consider a hypothetical world in which the only people still using Python were basically NumPy users. It would be a valid choice to move forward with Python development in a way that privileged such use, at the expense of "general purpose" use going forward. I'm not involved enough with Perl to know what that would be, just offering a meta-option to consider.
And let me close on what I opened with... this is a good "patch the holes" plan that should be all means moved forward with, to give space to breathe. I'm positive on the plan, not critical of it.
I actually find Go harder to work with JSON with for exactly those same reasons. With Go if I want to parse JSON into something I can call methods on, the JSON has to conform to something I can build a struct around. If the JSON is complicated in anyway that doesn't line up with Go's sense of structs I'm forced to drop to map[string]interface{} (or something like it). With Perl I can parse into the hashref equivalent of map[string]interface{} and still be able to bless it and call methods on it.
This isn't to say that Perl is better or Go is better, they just have different affordances. Perl is designed for loosely structured data and that causes all kinds of problems when you want to enforce highly structured data. Go is designed to handle strictly structured data and the ramp down is hard when you don't have that.
You are asking for a "thesis", for a unique proposition.
Well, maybe Perl 5's backwards-compatibility can be marketed, (or will emerge anyway, without any marketing), as a key advantage.
"These 20 year old Perl 5 scripts still run without any modifications on the new machine. Amazing!..."
There are not many languages that have this property of long-term stability. One of them is R , see recent Blogpost "Ode to R stability" by Dirk Eddelbüttel, one of the R authorities (and Debian Maintainer)
Paul Graham, whom some of you may have heard of, once wrote an essay about "What Languages Fix": http://paulgraham.com/fix.html
I think of it a bit differently, which is that languages have a thesis. (Not quite the same but a lot of overlap.) Paul writes that what Perl fixes is "Shell scripts/awk/sed are not enough like programming languages." I would personally rephrase it to something like "There isn't(/wasn't) a language dedicated enough to Getting It Done."
If you put yourself in the context of the time, this was absolutely true. Most languages for getting things done involved a lot of drama and boilerplate. Popular languages of the day would require you to implement your own hash table for a quick script, if you didn't have one on hand. Libraries for that existed of course, but the Internet wasn't really up and running the way it is now yet, and things were hard to find. Perl came in and provided a great Get It Done languages.
However, landscapes evolve over time and so do language theses. C++ is a great example of something that has changed, going from "C should have great support for object orientation" to something more like "C++ should be the choice for programmers who want zero-cost abstractions". Part of the reason for that change is that the former thesis is no longer a compelling one, on the grounds that "great object orientation support" is now simply table stakes for that sort of language. C++ could not drive forward on that thesis in 2021.
That is also Perl's real problem right now. It lacks a thesis. It has very narrow advantages in text munging still, but for almost anything else, I now have an abundance of languages that "get it done" just as well or better. For context, I've got about 15 years of Perl being my primary language under my belt, so that means something; it's not a secondary or tertiary language for me, and I still have plenty of choices to reach for. (Heck, I've even come to prefer Go for JSON munging quite a lot of the time, because with the right tooling it's really easy to parse JSON straight into objects that I can call methods on meaningfully, which is actually more convenient and useful to me than presenting me with a generic hashtable/array representation that I then have to write a lot of code to crawl over from the "outside".) The world has moved on, and Perl's problem isn't necessarily that it lost but that it won. It has successfully convinced the world that Getting It Done doesn't need to come with all the drama and paperwork and complexity of its late 1990s peers. But that means that just like C++ won and it couldn't continue operating on its "good OO" thesis, Perl needs a new thesis.
Moreover, it's going to have to be brutally honest in the selection of that thesis, because a lot of the obvious ones are already covered by Python, and trying to chase Python on its own turf is going to be a losing game. Perl 6/Raku also has its own thesis, which is now also essentially unavailable to Perl 5. Unfortunately, choosing a thesis successfully isn't necessarily about what the Perl team "wants" so much as where there is space in the programming language market, and in the intervening, gosh, decade or so that Perl 5 has been floating along without a thesis, a lot of the easy or obvious answers have been fairly well covered by other languages.
One thesis option is "Old perl code should degrade gracefully", which is the "declare victory and walk off into the sunset" option. To be honest, it's one that should be seriously considered. I think graceful retirement is a test a lot of language committees fail. Here I'd look for improved refactoring tools to help automatically translate old code into better code to modern standards and other such things being the standard, for instance.
But if the Perl 5/7 team wants a different thesis, it's something I think they need to decide consciously. I don't have a suggestion. But I can offer this word of hope; the space of possible theses is really quite large. The point of view where it looks like every possible language exists already is a point of view that is too narrowly stuck in the details of today. With just a bit of change in perspective, there's a lot of untapped fields.
Tempering that hope a bit, Perl's new thesis really needs to be something that Perl's existing code and community brings something powerful to. If you come up with a possible thesis, but look at it honestly and say "That's probably something better done with a brand new language entirely", it's probably not a functional thesis for Perl. And this does cut the space back somewhat. But some persistent thought may still find something interesting.
Personally, I'd also be looking carefully and honestly at what Perl is still doing and consider shedding old use cases/theses. For example, while Python is not experiencing a popularity crisis, consider a hypothetical world in which the only people still using Python were basically NumPy users. It would be a valid choice to move forward with Python development in a way that privileged such use, at the expense of "general purpose" use going forward. I'm not involved enough with Perl to know what that would be, just offering a meta-option to consider.
And let me close on what I opened with... this is a good "patch the holes" plan that should be all means moved forward with, to give space to breathe. I'm positive on the plan, not critical of it.