Well. I did test. I even installed an ancient perl 5.8.8 to make sure it hasn't been patched somewhere in between. You are right, I am wrong. I bow my head in shame.

But although I was wrong I still recommend to use variables for filehandles because a namespace collision may happen even though one carefully grepped the source code.

There's another issue and I misremembered it. I deliberately do something obviously stupid here to provoke the error.

#!/usr/bin/perl

use strict;
use warnings;

open say, '<', '/etc/nsswitch.conf'
  or die "Unable to open file1: $!\n";

print "Filehandle is now open!\n";

print "1: " . <say>;

exit;
[download]

This results in:

Filehandle is now open!
1: # /etc/nsswitch.conf
[download]

You'll probably also get a warning: 'Unquoted string "say" may clash with future reserved word at <script> line 8.' - something fishy is going on here. In a simple script you're likely to notice it. In a web- or GUI-driven application you probably don't.

Let's upgrade our perl and add a single line

use 5.010;
[download]

And suddenly the previously 'well-behaving' application goes boom.

Name "main::say" used only once: possible typo at <script> line 13.
Use of uninitialized value $_ in say at <script> line 8.

Can't use string ("1") as a symbol ref while "strict refs" in use at <
+script> line 8.
[download]

What?!!

'use 5.10' exports 'say()' into your namespace. And suddenly open() does not open a filehandle 'say' but a function say(). Boom. Trying to debug that in a real world application may cause some serious headscratching - it's not that obvious anymore - especially if there's nobody warning you that library 'xyz' may accidently export your favourite filehandle name in the future.

'use 5.10' exports 'say()' into your namespace.

No, it causes say to be recognized as an operator (like print) within the current lexical scope. Nothing to do with namespaces (packages) whatsoever.