The problem with using scalars for all I/O handles is all of the existing code that uses barewords; this solution maintains backwards compatibility at least for the simple cases that I expect are the most common.

Another problem is philosophical: removing features from the language because you do not like that style is not the Perl way. Perl advocates TIMTOWTDI; One True Right And Only Way is Python's niche and Python fills that niche very well.

Another problem is philosophical: removing features from the language because you do not like that style is not the Perl way.

I continue to fail to understand this argument. Who is saying "bareword filehandles should go away solely because I don't like the style"

Can you do Chesterton's Fence here? What technical arguments are there for discouraging bareword filehandles? Or, to make this easier, undeclared barewords in general?

What technical arguments are there for discouraging bareword filehandles?

There's the lack of scoping. You could use open(local *FOO, ...) to protect the caller, though. So I guess the real problem is that lack of scope-enforcement under use strict;.

Also, they're very low on the totem pole, so they can end up meaning something unexpected.

That is a short summary of the impression that I got from previous discussions on the topic of indirect filehandles in Perl, particularly in the case of code at the top-level of the main script, where a (global) bareword filehandle and a file-scope lexical have effectively the same scope.

There seems to be some confusion here — I am arguing that bareword filehandles should remain in the language, but suggesting a compromise of making bareword filehandles lexical variables. I expect that the arguments in favor of declaring bareword filehandles (and giving them lexical scope) are essentially the rationale for use strict 'subs' prohibiting the old "bareword-as-unquoted-string" behavior.

It would be far simpler to automatically convert

open(FOO, ...)
[download]

to

open(local *FOO, ...)
[download]

instead. While FOO is still technically global, the caller is protected.

Note that automatically limiting the scope of variables used as file handles will break code.

Or if barewords can no longer be used as a file handles, you could pre-declare them using

use Symbol qw( gensym );

sub FOO { state $fh = gensym(); $fh }

open(FOO, ...)
[download]

This is close, but does not actually give the same benefits. Lexical bareword filehandles move a bit of complexity into the parser, but allow the *foo{IO} slot to be removed from GV, simplifying the rest of the interpreter guts. Lexical bareword filehandles allow at least the simple cases to continue to work, even though I/O would be done only through =IO objects.

Some breakage is to be expected across major versions, but the goal is to maximize the amount of old code that continues to work, while still improving perl and its I/O handling.