Isn't this very confusing in almost all instances?
It's really not useful for variables, but can be very useful for functions, and since they're pretty much the same thing, you get the behavior for free. Although I haven't touched Lisp, my understanding is that Forth and Lisp have some conceptual similarities, but Forth is written by an engineer and Lisp by a computer scientist. Limit you for your own safety? Not a thing in Forth.
In this Kamby language, it looks like the bindings survive and are then accessible by name. When you're executing these [ ... ] blocks, a tree-shaped environment is built up which is then navigated with the :: operator, enabling it to simulate objects with fields.
The idea of there being a stack-like environment of variables which can survive the blocks in which they are bound is very useful in pattern matching and unification.
Under pattern matching, the successful path will have the cumulative variables arising from everything that has successfully matched, including some nested constructs. However, the search strategy will implicitly backtrack in searching for matches, and in backtracking, it will implicitly erase any variables accumulated in the discarded paths.
In the TXR pattern language, I invented some mechanisms for controlling the proliferation of variables. When a pattern function is used, only those variables that correspond to its arguments can emerge.
$ txr -B -c '@(define fun (arg1 arg2))
@(bind arg1 "a1")
@(bind arg2 "a2")
@(bind arg3 "a3")
@(end)
@(fun x y)'
y="a2"
x="a1"
If we bind an argument, the parameter will be bound on entry into the function, and so then has to unify in the subsequent bind directive. It does if we pass the value "a1":
txr -B -c '@(define fun (arg1 arg2))
@(bind arg1 "a1")
@(bind arg2 "a2")
@(bind arg3 "a3")
@(end)
@(fun "a1" y)'
y="a2"
txr -B -c '@(define fun (arg1 arg2))
@(bind arg1 "a1")
@(bind arg2 "a2")
@(bind arg3 "a3")
@(end)
@(fun "foo" y)'
false
How is this less confusing? := vs = will either push a new variable on top of a stack of identically named variables, or change the content of the top element on that stack? Why would anyone want any of that? Shadow variables are usually associated with hard-to-find-bugs, (i.e. forgetting that there is already a variable named 'xyz' in the current scope) not some great feature we want more of..