That's already valid syntax that already does something completely different.

Code:

FD=0
cat <&$FD

Shoehorning your solution in there will break existing code. Pick something else. ...aside from the fact that you want this to be a shell language, that is. Among other things that means weak typing. If you don't want a shell language, don't use a shell language. No you don't.

Code:

<file_in >file_out cat

[edit] that doesn't work for shell builtins like while. You can bodge it in with <file cat | while but that's not elegant. The ability to do so could be a useful addition.

Then you check if the file exists, and open it. You have all those features already. Nothing's forcing you to redirect into code blocks except that it frequently makes sense to do so; if you don't want to use this feature sensibly, don't use a shell language.

Writing shell code frequently means different decisions about how you lay out your code because of the way code blocks work. If you don't want that, don't use a shell. I'd presume not. Why should {f} close just because it's on the same line? It's not like stdin closes.