My point is that adding scoped lifetime management to file descriptors in a shell wouldn't fall nearly as far outside the current model as you suggest.

So what's the problem? I don't see how anything I've described impacts file descriptors 0-2 or pipelining in general.

By "between commands" you mean between external commands, i.e. programs on the PATH, right? As opposed to shell functions, shell extensions, etc...

When the shell hands a file descriptor to a process (on exec()), it doesn't have to care what that process does with the FD. The underlying mechanism is as it always has been: the file occupies a numbered slot in the new process's file descriptor table.

It can be hard to come up with a good syntax when you're trying to serve multiple needs. I don't believe there's any reason this feature would make a mess of the syntax, however. If the variable $f is a "file" object (i.e. an open file descriptor, assigned some numeric FD within the shell itself which the user actually doesn't need to know...)

Code:

read x < $f   #Is that quite simple enough?  Alternately, "read x <&$f" would make it plain that $f is an open file and not a filename.  A shell could support either syntax, or both.
some_command 8<&$f   #And there's no reason it couldn't work with the existing numeric redirection syntax either...
some_command $f   # It's actually not too hard to make this do what the user intends...

There's a couple ways the last one could be handled:

First, the shell could handle it like process redirection: assign the file $f some numeric FD in the new process, then in place of the argument $f, substitute /dev/fd/(some number)
Second, it could be as above but with just the numeric FD rather than the /dev/fd path. Considering how few command-line tools actually provide any support for doing something with a numeric FD other than 0-2, it probably doesn't matter - though the first approach would work with more commands since /dev/fd/* can be used like any other filename...
Alternately, the shell could reject this as a type error. It's an easy enough condition to detect, and the shell could even provide a useful error message, explaining that you have to use redirection syntax to pass an open file descriptor to a process.

Honestly, the whole /dev/fd thing in process substitution always struck me as kind of hokey... Though that may just be because I hadn't heard of /dev/fd before (/dev/tcp struck me as even more hokey - in large part because the directory doesn't exist...) But it does its job, supplies the identity of an open file descriptor to a command being called as if it were a filename...

I think that takes care of "scoped", as you say - though the syntax could be better (you increase the nesting level each time you add an additional file, unless you open all the files in the same place... And if I'm not mistaken, the files can only be opened at the end of the block (I tried it at the beginning of a block, in bash, and it didn't work), which is kind of awkward IMO. When reading code I think it's more useful to be able to see what file is what at the point you start using them.

It's fine to point at an example where you're just reading one file, or reading one file and writing another, and say you don't need to deal with numeric FDs in the shell. But if you're opening more than one for reading, or you have different subroutines that are all operating on different files, then you certainly do need to think about where those files are going to go.

Bash already provides a syntax for auto-assigning a file descriptor when opening a file, of course - and that goes a long way toward making the situation nicer: you can open the file, pick an FD for it, and assign the number of that FD to an environment variable all with a compact bit of redirection syntax. That's about what you get from using file descriptors in C - the programmer takes responsibility for not overwriting the variable containing an important file descriptor and also takes responsibility for closing file descriptors when it's time. It's quite workable, really. Going C++ style with RAII and so on isn't strictly necessary, it just strikes me as something that could be useful.

But, of course, the proof is in the implementation. Whether or not an idea sounds good, specifics of execution can make all the difference.