I'll try a different tack. In order for this to be more than a documentation problem, a piece of < 5.10 code that works correctly, would have to fail when run on 5.10.

So, let's try and construct a piece of code that would meet that criteria.

1. We need a piece of tainted data:

   my $tainted = <STDIN>;
   [download]

2. Next, we need to pack that data:

   my $stillTainted = pack 'a*', $tainted;
   [download]

3. Finally, we need to use the still tainted data to do something that would have rejected it:

   open my $fh, '>', $stillTainted or die $!;
   [download]

And there's the problem. With < 5.10, that will always fail with Insecure dependency in open while running with -T switch ..., because they never did anything to untaint it. And any usage that wouldn't fail under < 5.10, still won't fail (and will still be secure) under 5.10.

The above sequence wouldn't fail under 5.10, but the problem only affects new code, and that can be addressed by a documentation change (if that's the right way to go), rather than a code change.

My point was that it doesn't make any existing (pre-5.10) code that works, less secure when that code is moved to 5.10, because if it worked securly pre-5.10, it'll still work securely.