Why would the code be updated.

I don't know...yet. That's more-or-less the definition of maintenance: making changes when the code needs to be updated for some currently unpredictable reason. A few obvious possibilities:

• The data to be analysed alters in structure, which requires a new algorithm to detect.
• You decide that you want even greater compression by more detailed (possibly recursive) detection of repetition patterns.
• You encounter another very-similar-but-not-identical task, and decide to refactor the subroutine to handle both, rather than copy-and-pasting.
• You find another improvement on the current algorithm, which requires a modification of the existing code.
• You discover a bug or limitation in the current algorithm that requires a modification of the existing code.
• P5P discover a bug or limitation in index() (perhaps to do with Unicode edge-cases) and rewrite it correctly, which makes it vastly slower.
• P5P deprecates and prepares to remove index() (presumably because it's just too much like smartmatching ;-)

Why would anyone modify it, when it performs the required task as is.

Again, I don't know...yet. A couple of obvious possibilities:

• Because the required task may change or evolve.
• Because the code may eventually be found not to perform the task correctly as is.
• Because the insatiable need for speed, on ever-growing string lengths, may force you to improve the existing algorithm.

I added a couple of print statements...

Yes, I use that approach too, in preference to the horrors of the Perl debugger. But that's still not nearly as convenient, quick, explanatory, or powerful as Regexp::Debugger is on regexes.

And look...you're now modifying the code! That itself is a potential source of bugs. You may never have accidentally left a "debugging print" in code, but I certainly have. I've even shipped code with them left in. Which eventually leads to bug-reports and more maintenance. :-(

As you point out, I am only reporting my own preferences for code maintenance. But those preference aren't merely whims; they're based on long experience of my own abilities and limitations as a developer, and my own psychology and habits as a coder. And I honesty believe that many far-better developers and coders than me would also benefit from endeavouring to write code that is less subtle, more declarative, has fewer side-effects (i.e. variables), doesn't manually iterate through infinite loops, and is easier to debug without actually having to modify the code to do so.

Sure, sometimes you need subtlety. And sometimes you have to write "manual" code. The unbeatable performance of hdb's excellent solution demonstrates that perfectly. But I will continue to believe that such code should be the exception, not the paradigm.