Wrong. The other time it knows it's done with a file descriptor is when that file descriptor is closed.

So why should "exec $fd<&-" be the only way to tell the shell it's time to close a file descriptor?

That's all I'm describing here - just another way to control the lifetime of an open file descriptor in a shell. The shell doesn't need to be psychic in order to know when a local variable goes out of scope, or when a global variable is unset. That's all you need for the RAII method of resource management.

If an open file descriptor in the shell is tied to the lifetime of a variable binding - what is the scenario in which that file needs to be open, but isn't because the shell decided it was time to close it?

It seems to me you have an extraordinarily limited view of what qualifies as a shell.

And, you know, I don't expect you're the only one. When I look at the problem of trying to enhance the shell (and I understand that what I consider "enhancement" others may very well consider garbage) - it seems likely to me that most of the people who actually still use the shell, probably don't want to see it change in any significant way. If they wanted to use something else, they probably already would be.

Nevertheless, I want to try to make something better.

I want to make a better shell language. I like the basic approach of the Unix shell but I think there's room for improvement in the execution. I mean, seriously - do you think the existing shell is perfect? Really?

Obviously, there is a chance that anything I come up with won't be an improvement. It may not even be worth running at all. Who knows? But we don't get nice things if people don't try to strike out in a new direction once in a while.

I really don't understand why you think anything I've suggested would change that model, or break those assumptions.

But don't worry, I won't ever break into your machine and replace your shell. :P'