I think the other problem was that Perl 6 came out and was totally incompatible with previous versions. Python did something similar with 2->3 and it caused huge problems.
That was later though. Interest in Perl was already declining a bit then. And the problem was more that the design and implementation of Perl 6 (now Raku) took extremely long, and attention to Perl 5 suffered from that, as Perlistas thought Perl 6 would be the Next Great Thing.
Not "almost", it is a completely new language with a passing ressemblance and IIRC was by and large advertised as such from the get go; the name "Perl" was kept as it was a spiritual successor, which they realised made it confusing so they changed it to Raku.
Perl 5 and 6/Raku have as much in common than Perl 5 and Ruby have.
IIRC was by and large advertised as such from the get go
It was not. For many years it was advertised as the next version of Perl (with the intent being perhaps a Perl 5.10 release and then no more major releases with the 5 version number), then years later a "sister language", and then finally now (but not retroactively) a "completely new language in the Perl family".
Very early (2000) the goal was for Perl 6 to be a rewrite[0]. There's no way this would have been a 5.x, especially given how the Perl 5 parser works and the class of warts that were aimed to be addressed:
> Perl 6 To Be Complete Rewrite (But Not What You Think)
> Perl 5 will not be abandoned, but will primarily be concerned with bugfixes both major and minor.
> The meeting for members of the perl5-porters mailing list was the result of an earlier, smaller meeting of Wall, Nathan Torkington, Chip Salzenberg, and others who basically decided that Perl needed to be fixed in certain ways, and that a rewrite was the best way to do it.
Quickly, being free from backwards compatibility gave room to try stuff out, and given the length of that design process, this resulted in features that they found out could be immediately useful if backported in some way to Perl 5:
> First, Perl 5 isn’t going anywhere. If anything, the rate of patches and changes to the code has increased. Cleanups from Ponie and the Phalanx project continue to improve the design and implementation, and new features from Perl 6 are making their way into Perl 5.
> Second, the opportunity to do the right thing without fear of breaking backwards compatibility opened up a lot of possibilities for impressive new features.
Granted, there's the following bit in the 2000 post:
> have a clear and automated migration path, which may include a backward compatibility mode
But back then (ca 2002-2005) I was only a Perl apprentice and a very junior developer yet it still struck me that the discussions highlighted differences that were expansive and fundamental enough that "next version of Perl" meant Perl 6 would be to Perl 5 what e.g Mac OS X† was to macOS 8/9 and (in retrospect since that happened only later) significantly different in class from e.g Python 2 to 3 or MRI to YARV.
That was my perception of it anyway; probably they weren't entirely clear what was the actual goal, hence a lot of bits were open to interpretation, and it got refined and bounced back and forth around a general baseline direction over 5-10 years.
