in reply to RFC: (Do Not) Modify the System Perl

I'd maybe point out in the "you can break the OS" part that while the OS may include a version that has what are now known bugs, sometimes there are features that effectively depend on those because the OS counts on the bad behavior for some reason. All the more reason to wait for the system Perl to get updated with system updates.

Another pro is that if you're trying to either test someone else's code that depends on the version, or test a claimed bug (e.g. posted at PM) it's much easier to do if you're set up to switch among Perl installs at will, and can install new ones safely and cleanly with something like Perlbrew.

It's easier to upgrade to a new Perl if you don't have to do it all at once. You can install the latest and greatest, write new code with it, etc. without worrying about breaking any of your existing code and having to spend a bunch of unplanned time fixing it. This is especially useful for "intermittent" developers like me. (FWIW, I do find that Perl tends to have very good backward compatibility and can't recall the last time I ran into a conflict, unlike Ruby, which sometimes makes me crazy with incompatible dependencies.