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.

how do they work with current indirect filehandles?

What's an "indirect filehandles"? You mean a lexical file handles (e.g. open(my $fh, ...))?

Perl usually accepts

• A reference to an IO object.
• A glob containing a reference to an IO object.
• A reference to a glob containing a reference to an IO object.
• A string naming a glob containing a reference to an IO object.

open(my $fh, ...) creates the third one. Every XS module that deals with file handles should support this.

The last is the least supported by XS functions, if at all.

The first is probably the next-least supported. The very ability to have references to IO object is relatively recent. That said, I mispoke about the extent of the breakage of CPAN that only support this type of handle would cause. In fact, I really don't know how much of CPAN would break if you suddenly changes the primary way to pass file handles around.

however, the simple case I was considering was more like:

That's irrelevant. I never said it would never work.

If I said that then I was mistaken

This is what you said. Clear as mud, I know. But there's no mention of Perl 7.

the goal was to provide an alternative to the removal of features suggested in the original Perl 7 announcement

Well, that's not entirely true, right? We're specifically talking about the removal of barewords. Maybe you have other features in mind too, but they're not being discussed here. So, like I said, the problem you're trying to solve is a need to avoid barewords. So my comment stands. What I provided a few posts up solves the problem a lot more simply and cleanly.