lexicals declared at file-scope are global variables

Yes, you have a point, but:

acting like they are somehow different

No, they are in fact different: as I've said plenty of times now, bareword filehandles are not protected against typos and they clash with package and sub names, among other things. There is no remedy for this other than "being careful" (good luck in the long term) or using lexicals. On the other hand:

the additional risk that file-scope lexicals can be shared across packages if multiple packages are defined in the same file

While not wrong, this is only true under certain circumstances: if there are multiple packages in the same file, and those packages are in the same lexical scope, and the user has similarly named lexicals and makes a typo that happens to reference a previously declared lexical.

package main;
open my $fh1, '>', 'x.txt' or die $!;
print $fh1 "foo";
close $fh1;
package foo;
open my $fh2, '>', 'y.txt' or die $!;
print $fh1 "bar";  # oops!
close $fh2;
[download]

there really is almost no difference between [bareword filehandles] and lexical file handles — declaring a lexical at file-scope has almost exactly the same effect, and exactly the same effect if the convention of maintaining a 1:1 mapping between files and packages is followed

Once again, no, and I find this insistence quite misleading. If you're going to recommend bareword filehandles, at least acknowledge the issues they have.

bareword filehandles are not protected against typos

This is not entirely correct. While a typo in a bareword filehandle will not produce a compile-time error, it will produce a warning at run-time about using an unopened filehandle, and a unique typo will produce a compile-time warning about a name "used only once: possible typo".

they clash with package and sub names ... There is no remedy for this other than "being careful"

I strongly disagree with that statement; the standard conventions in Perl are to make bareword filehandles ALL UPPERCASE, while package names are MixedCase. Bareword filehandles do not clash with sub names at all: they are distinguished by syntax in all reasonable cases and are separate GV slots. The same name is allowed to have both a CODE value and an IO value in Perl.

While not wrong, this is only true under certain circumstances: if there are multiple packages in the same file, and those packages are in the same lexical scope, and the user has similarly named lexicals and makes a typo that happens to reference a previously declared lexical.

That was not specific to filehandles, but applies to file-scope lexical variables in general. A file-scope lexical is in-scope for the rest of the file. If you define multiple packages in the same file after declaring a file-scope lexical, they will all invisibly share that value. A bareword filehandle is in-scope for the rest of the containing package, possibly also the containing file, since the parser takes its use as a hint. These scopes have the same extent. A lexical declared at file-scope is indistinguishable from a global variable in good practice. (Declaring multiple packages in the same file is not good practice unless the "inner" packages are very closely related to the "main" package in the file.)

I find this insistence quite misleading

I find similar insistences that a lexical declared at file-scope is somehow not effectively a global variable merely because it is not in the symbol table similarly misleading. File-scope cuts across all other structures in the same file defined after a declaration. All following subs close over file-scope lexicals. Lexical variables declared at file scope have the same risks as global variables (use strict / use vars) and need to be recognized as such. This is not limited to filehandles, but it is often touted as a problem with bareword filehandles. At file-scope, lexicals have the same problem.

a typo ... will produce a warning

I know, since I'm the one who corrected you about this. And since lexicals cause compile-time errors, this is an argument for lexicals instead of bareword filehandles.

"being careful" ... conventions ... in good practice

These three are the same thing, and we've been over this too.

Bareword filehandles do not clash with sub names at all

You're mistaken, see the references I gave.

That was not specific to filehandles ... These scopes have the same extent.

Once again you're just explaining something to me that I already know, while missing the point I was making: you said lexicals have an additional risk, which I agreed with, while pointing out that the scope of the potential issue is both easily remedied and the issue arguably smaller than all the issues that bareword filehandles have.

A lexical declared at file-scope is indistinguishable from a global variable in good practice.

There's that insistence again. And just in case your point happens to be that code using bareword filehandles, when correctly written, runs just like code using lexicals, then while true, I think this fails to recognize the action-at-a-distance issue I named. While the cost of this may not be immediately apparent and you may not have personally run into this so you may not know this feeling, ask anyone who's had to maintain code that uses globals how brittle that feels, or especially anyone who's had to debug an action-at-a-distance bug what that's like and what the cost was.

I find similar insistences that a lexical declared at file-scope is somehow not effectively a global variable merely because it is not in the symbol table similarly misleading.

Who's insisting this?? Not me...

Lexical variables declared at file scope have the same risks as global variables (use strict / use vars) and need to be recognized as such.

Once again I fail to see how this has anything to do with an argument for using bareword filehandles instead of lexicals.

At file-scope, lexicals have the same problem.

That lexicals and barewords share an issue or two may be true, but neither is this a counterargument to anything I said, nor is this what you said that I was responding to. Saying barewords have "exactly the same effect" while not acknowledging that barewords have more problems than lexicals is misleading and potentially dangerous to people who aren't aware of the issues. Imagine someone writing a short, single-package daemon:

print STATUSMAIL "Error report:\n";
print STAIUSMAIL "IMPORTANT ERROR\n" if some_rare_error_condition();
[download]

Lexicals would have obviously prevented this. And yes, I'm aware of "but conventions" and "but warnings" and "but testing" - I find the analogy in the anonymous post fitting: my car may or may not have a crumplench zone, airbags, and autopilot, and yes, seatbelts may not be a silver bullet, can be used wrong, and can cause bruises, but guess what, I'm still going to argue that the habit of always putting on a seatbelt is a Good Thing for many good reasons (while educating people on how to do it right when necessary), and one major reason is that there are other people on the road too. And I'm still going to take issue with people who say otherwise, and to me, "I strongly favor the use of bareword filehandles at top-level in preference to declaring lexicals at file-scope and thinking that you are safe" reads as "I strongly favor not wearing a seatbelt in specific circumstances in preference to wearing a seatbelt and thinking that driving is perfectly safe." In response to my arguments, you just seem to keep repeating various permutations of "seatbelts and driving overall aren't perfectly safe", which may be true, but is not an argument against seatbelts. And just to be clear, yes I'm equating lexicals to seatbelts because they protect against all of the issues of bareword filehandles, and I have yet to hear arguments against this.

Taking a step back, at this point I'm just seeing a lot of nitpicking, explaining things I know, and repetitions of things we've been over, and continuing the "discussion" in this manner is not helpful. So far, I've carefully read all of your posts in hopes that I'd find an actual, concrete argument for bareword filehandles (as I asked), and also arguments against the various issues that I named (that isn't nitpicking), because I was honestly curious if either exist. But at this point I'm more worried that I've insulted your personal coding style, which I said isn't why I'm arguing this, so I'm sorry if that's the case.

What I'm arguing for is what to recommend to others, in particular (but not limited to) newcomers - in that respect, my viewpoint remains unchanged from what I said: I don't really see what arguments for bareword filehandles are left, other than making newcomers to the language aware of the fact that they exist but are not a best practice.

Edit: Clarified second paragraph.

No, it's a different quality if a variable can be accessed and altered in a different file from another author.

Furthermore putting a file scoped lexical behind the last sub would protect it from becoming closed over.

Package vars are accessible nonetheless, no matter where you define them.

perlglossary even makes a distinction between package vars and special vars.

In Perl, only certain special variables are truly global—most variables (and all subroutines) exist only in the current package.