Lexical scoping is the most straightforward, least surprising scoping strategy I've seen. With lexical closures it allows for some tremendously powerful constructs.
Alas Tcl is more complicated. It's sort of dynamic but not quite depending on how variables are accessed. For one thing a proc definition provides a separate scope from the global variable scope. If we define:
set b 5 ;# global
proc w {a} {
# upvar 1 b b
+ $a $b ;# "can't read 'b': no such variable"
}
proc x {} {
set b 2 ;# local
w 0
}
x ;# error re: no such variable 'b'
Of course the call to w in x doesn't operate under lexical scope since procedures are global and can't access variables inside another procedure's scope.
It is possible under some conditions to mimic lexical scope using the upvar command. In the case of proc w, uncommenting the upvar call would reference var b in the calling proc (or stack frame).
Wow, written out that is kinda "mind-boggling"! But in practice it's not a problem keeping it straight, at least most of the time...
The thing with upvar (and uplevel) is that by default upvar refers to variables in the caller of the current proc. But when a proc is called indirectly (e.g., a callback proc) then the variable upvar is intended to reference may be 2 or more frames above. Using something like "upvar #2 refvar var" works as expected. It's analogous to deferencing pointers in C when there are >1 levels of indirection.
Is there any programming language that doesn't have some confusing rules? If a language is going to be useful the answer is bound to be "no". It's a curious how we get used to a particular (or even peculiar) syntax. When used long enough it begins to feel "natural" and obvious, and find it amazing how anyone would have difficulty understanding how it works.