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.

This is close, but does not actually give the same benefits

You said the problem you're solving is a need to avoid barewords. (You didn't justify that, but fine, I can imagine a reason or two.) What I provided solves the problem. If your solution provides different benefits, does that mean it doesn't solve the stated problem?

Ok, let's assumes you meant it provides additional benefits. We'll come back to that.

allow the *foo{IO} slot to be removed from GV

No, it doesn't. You can't break every XS module that interacts with Perl file handles.

Lexical bareword filehandles allow at least the simple cases to continue to work

No it doesn't. It would cause the following to fail:

sub f {
   print FH ...;
}

open FH, '>', ...;
f();
[download]

Lexical bareword filehandles move a bit of complexity into the parser

Except the complexity isn't moved. Your solution adds complexity. Your proposal invents a whole new type system based on heuristics that's nothing like anything in Perl already, when you could simply localize the globs implicitly. This doesn't just add complexity in the parser; it really complicates the language. This affects programmers, not just the people working on perl itself, so this is far worse.

improving perl and its I/O handling.

You said the goal was to avoid barewords. You didn't identify any "problem with I/O handling", whatever that means.

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.

Everything I said assumed that the goal as worthwhile. None of the my objections have been about the goal, which would necessarily cause breakage; that's a separate discussion. That means converting open(FOO, ...) to open(local *FOO, ...) would cause that same breakage. But it's a far far better solution to the stated goal.

Earlier, I said I'll presume you meant your solution provides additional benefits over the one I proposed. Well, if that's the case, I'm still waiting to see what they are.

---

Update: This was was posted without my knowledge while I was still composing. I ended up with two posts which I've merged.

allow the *foo{IO} slot to be removed from GV

No, it doesn't. You can't break every XS module that interacts with Perl file handles.

If XS modules depend on the *foo{IO} slot today, then how do they work with current indirect filehandles? Or are indirect filehandles actually glob references, even though they print as =IO?

It would cause the following to fail

You are correct; however, the simple case I was considering was more like:

open INPUT, '<', $file or die ...;
while (<INPUT>) {
  ...
}
close INPUT;
[download]

You said the goal was to avoid barewords.

If I said that then I was mistaken; the goal was to provide an alternative to the removal of features suggested in the original Perl 7 announcement that I found objectionable. The improvements to I/O handling envisioned are simplifications by making all filehandles indirect filehandles, while retaining at least some of the existing syntax.