You mention several "changes" that you perceive in code over the time, and you seem to imply that most of them are "improvements".

I for one do not see the move from what you call old style to OO-style an improvement if it is done only for that reason. OO-style has its merits in a lot of cases but it being more moderd by perception is never a good reason to refactor code. Never.

The thing I miss in you very elaborate and well readable posts is what I think is the most important thing in module code: consistency. Reading your posts, I have a gut fealing that your documentation is in good shape. You seem to be capable of explaining your thoughts and goals which imho is an indication that you do so in the docs too.

As others have said, your target audience is important. If you are backporting new(ish) features from perl5.12 to perl5.older, you really care about what versions run the code on what architectures. CPANTESTERS is your help there as I presume you do not have 100+ perl releases running on 40+ architectures. If you are indeed making your code to run on 5.6, some more modern syntax won't even be available.

If your code is aimed at maintenance by many (a public git repo is a nice start), make your style guide public. Explain where your decisions stem from and "force" a style on the other coders. Using Perl::Tidy (perltidy) - and providing a working .perltydyrc can help the others. With what I started: consistency is way more important to be able to read code from others that to follow the style-du-jour.