Here is the basic concept: don't encode information into variable
names or any names in Tcl. Don't encode type information, don't encode
things that you think exist in Tcl (which don't). Strings don't become
variable names until they are used as variable names

You may think this is off base, but consider several commands: lappend
and linsert. Lappend take the name of a list, but linsert takes the
actual list. Your suggestion would be that lappend would change so
that you would do [lappend &mylist a b c]. Otherwise you have a major
distinction between pass by ref and by name. Then we could move on to
the array functions [array get &myarray]. Wow, that looks so cool. If
you don't require this, then you have two different ways of writing
commands. Or maybe you think there should be a difference between
procs (defined by proc) and commands? I don't.

You might try looking at namespaces if you don't like upvar. It is
just like a named stack/level. And it maintains state for you.

"
  Normally, parameters are passed by value.
  If a procedure takes a parameter whose name starts with a '&',
  like &par, then it is meant to pass in the variable as such.
  Inside the procedure, par is then linked to a caller's variable
  whose name was given for &par in the call to the procedure.
  For general information about linking variables, see command "upvar".
"

upvar ?level? otherVar myVar ?otherVar myVar ...?

Also, you have to consider the case where the proc is supposed to
create the variable in the caller's space. The correct way to do that
is to pass in a name. [Upvar a b] is saying more than pass by
reference, it is saying create/reference a one level up and link it to
b right here.

I snipped the rest, because I think it's void.  If you check
above example, you'll likely agree.

I've posted examples of both proc-definition and usage
of my proposal almost every other post, so please reread
one of them, and discuss them, not some rubbish that I
would never suggest for tcl.

so I still think it is the right tool for the job - yes you can use a
screwdriver to punch a hole in the wall, or whack a nail, or pry
something apart, but it's still a screwdriver, and driving screws
is it's primary job.

Upvar is used to implement pass-by-reference semantics.

Uplevel is used to implement pass-by-name semantics.

What does upvar have to do with pass-by-name semantics?

upvar:
% proc foo {vx} { upvar 1 $vx x; lappend x 42 }
% foo lclVar
In my eyes, *this* is call-by-*name*.

new feature:
% proc foo {&x} { lappend x 42 }
% foo lclVar
In my eyes, *this*, too, is call-by-*name*.

uplevel:
% proc foo {vx} { uplevel 1 [list lappend $vx 42] }
% foo lclVar
In my eyes, *this*, too, is call-by-*name*.

1) When getting invoked as a CGI or as an SMTP handler, I had a routine
that would take all the variables from the headers (user-agent, or
subject:, for example) and create variables prefixed with SMTP_ or HTTP_
in the caller, for easy access:
    access_headers
    if {[info exists HTTP_content_length]} {
       [read $in $HTTP_content_length]
    }
    if {[info exists SMTP_reply_to]} {
      set destination $SMTP_reply_to
    } else {
      set destination $SMTP_from
    }
Not unlike the way PHP used to work, except PHP was dumb enough not to
use a distinct namespace for such variables, so it turned into a headache.

2) When making a complex event-driven mechanism (as in, each event had
the possibility of doing something rather complex), I used it to suck
the parent's locals (from a distinct list) into each child in the chain,
as it prevented the use of globals that had to be cleaned up when the
transaction finished. Some of the routines were nested a number of
layers deep, and needed things like the name and password, the customer
ID, the transaction to be performed, a number of different "joins" from
database tables, instantiations of and interactions with COM objects,
shopping carts full of stuff being bought, and so on.  Nowadays, passing
a [dict] full of stuff around might work better, but at the time, having
a list of names of arrays where things were stored and just sharing them
across stack frames made sense.

proc foo {&thing &stuff} {set think 42; return $stuff}

set topthing 13
set stuff(13) "Is 13"
set stuff(42) "Is 42"
foo topthing stuff($topthing)

What does that return?

If it returns "Is 42", then it's call by name. If it returns "Is 13",
it's call by reference.  You could *make* it pass-by-name, by putting
braces around the passed-by-name arguments and calling uplevel inside
foo, but upvar is pass by reference, not by name.

These words *do* have technical meanings. It's not a question of what it
means in your eyes. :-)

If instead I call it "call-by-reference" some others misunderstand me
as wishing to call "lappend &var elem ..." (which of course I *don't*!)

So I take it as how it makes most sense for tcl, which is:
  either I call by value,  with a "$var" on caller's side
  or I call by reference/name, with just "var"
caller and callee must of course agree in their interpretation
of the argument, otherwise it won't work ...

What is described on the wiki-page as "call by name" would be very
clumsy to do in tcl.  Also, tcl has no reference type as such, so
passing a *name* of a variable (to be effectively upvar'ed) is
as near to other languages' *references* as we can get in Tcl.

As in:

proc RepeatUntilLoop {body condition} {
     while {1} {
        uplevel $body
        if {[uplevel [list expr $condition]]} {
            break
        }
     }

Maybe this is why this idea is confusing me. In C you use the &
operator in client code, because you are asking the called function to
use your memory location. The client code sets up the memory, or at
least knows that it is setup, and then asks the caller to put
something in it, or maybe update it in place. But there are many
different reasons for this, which simply do not exist in Tcl. In other
words, & and * exist in C, but in Tcl we have $ to replace the *
operator. The & operator isn't needed.

The fact that in Tcl you can directly address any variable or proc by
name, or use the same name in different contexts to address different
procs is a good thing. Upvar is just one way to address a variable in
another context, and if developers are having trouble using it,
hopefully they will keep their code locked away until they can type in
a few extra lines of code.

Also, these upvar statements are very helpful documentation. It is
common to place them at the top of a proc body because they are
important, they are a major feature of Tcl programming. Hiding away
important features may seem cool, but it ain't. And, again, if
developers can't figure this out, just wait 'til they try to debug
their broken code. Suddently the hidden magic isn't such a great
thing.

I'm simply pointing out that there are places it's useful that aren't
"call by reference" that I wouldn't call "hacky" either. Or at least not
*too* hacky - the bit of looking upwards for events was pretty hacky. ;-)

I certainly would think it would be a bad move to say you could *only*
use it for pass-by-reference.

I use upvar a lot, too, outside the context of "call by reference". I'm
not sure if that matters in this debate or not but figured I might as
well toss my hat into the ring.

I write pseudo-OO code all the time that looks roughly like this:

proc ::myclass::constructor {id args} {
     ...
     interp alias {} $id {} ::myclass::proxy $id
     upvar #0 ::myclass::data_$id data
     array set data $args
    ...

Personally I get pissed off at myself when I use different names for
the same thing in different procs. So the trend is to notice these
inconsistent usages and remove them.

Any useful body of code would therefor trend to remove your partial
solution to a more general solution so that code appears consistent.
Simply looking at one or two procs as an example is totally pointless.
Consistency is much more important than shortcut code. This is the
disease of languages like C, where you can skip certain syntax
requirements under certain conditions. It helps nobody in the long
run.

It is obviously even more important for an interpreted language to
have strict syntax than a compiled language, but even compiled
languages are aided by this. Remember that the most difficult
operation is parsing and compiling. Adding anything to this is a HUGE
change. If you don't appreciate this, then bone up on the problem.

It's most frequently used to link a local variable to a variable
in the caller's context, named in an argument to the procedure.
[upvar] is more powerful than it needs to be *for this particular use*.

I was using the term "pass-by-name" in an informal sense,
meaning "you pass the name of a variable instead of its value."

But he's absolutely right:  Tcl _always_ uses call-by-value;
to get call-by-reference, the callee uses [upvar 1]
and the caller passes a variable name; and to get call-by-name
semantics (in the Algol 60 sense), the callee uses [uplevel 1]
and the caller passes in a script.