One could release this "language" as a distribution of the inner language's compiler together with a wrapper (like C++ originally was to C), that, rather than adding features and compiling down, just analyzes the source file and errors out on use of forbidden syntax; or, if no forbidden syntax is used, just passes your code straight through to the inner compiler. A bit like a pre-commit-hook style checker, but a pre-compile-hook style checker.
Those commands effectively make any tcl function be able to operate as an f-expr (in old lisp parlance). Effectively (this is a simplification), an fexpr is a runtime macro, as opposed to the more traditional lispy compiletime macro.
Its what makes tcl feel more like a lisp-for-strings. Much of the truly horrible tcl code out there in the wild is from folks who try to use tcl as just another c-style scripting language.
Treat it more as a lisp, and it some of its inherent elegance shines through.
My $0.02 anyway ...
Lisp people had bad ideas along the way. They recognized that this is the case and got rid of those ideas, in some cases documenting some of those choices.
That man page isn't the most clear. upvar gives you a way to modify a variable in the calling context (and I think it can go up more than one stack frame).
It's a way to pass by reference rather than the default pass by value (how tcl passes is more complicated than that for performance but the default semantics are pass by value).
It's a facepalm-stupid thing to put into a programming language. Programs that use it will not be efficently compilable; the compiled code will have to provide upvar access similarly in order to make them work.
When compiling a function, you don't know which callee might ask for an upvar, so you can't optimize away variables or keep them in registers across calls.