Thanks for the clarification. Unfortunately, I don't think there's a straightforward "Yes" or "No" answer to this.

In a work situation, you'll often be required to code to a certain version, which could be a very old version. There can be many reasons for this, some are appallingly bad reasons; however, if you've agreed to take on a contract working with legacy code, then you're going to have to develop in an old version.

In another work scenario, you may be required to upgrade old code to a more recent version. Now it becomes important to understand both the features of old and new versions.

Even when working with older versions, you should aim to write your code such that it's easily converted to newer versions or, better still, requires no conversion. Just because the old version didn't pick up this classic syntax error:

for my $item qw(item1 item2 item3) {
    # do something with $item here
}
[download]

does not mean you should include such an unreported error in new code written for an old version. See "perl5180delta: qw(...) can no longer be used as parentheses" if you're unfamiliar with that particular problem; be aware, that's just an isolated example of code that didn't follow the published syntax, but got away with it in earlier versions.

As already indicated in my original response, I'll tend to avoid newer features in code I supply on this site. I'll generally aim to explain a technique using code that should work with whatever version of Perl the OP is using. If you're in a situation where you're mentoring, I'd recommend a similar approach; for example, use the well-known "@$aref" to initially explain a point, then introduce "$aref->@*" as a newer feature.

For my personal code, I use a lot of the newest features; although, for anything that's not simply a "let's test this new syntax" script, I avoid experimental features. They will come back to bite you in the bum when their implementation is changed or, when deemed a failed experiment, removed completely. Don't use experimental features in production code.

Anyway, there's a series of scenarios where "Yes", "No", "Maybe" or "Depends" could all be valid answers. You'll need to make separate judgement calls for each; based on context, requirements, in-house standards and so on.