You simply can't do upward funargs in a C-family language without breaking the memory and activation-record model of the language. For example, let's say C++ had upward funargs. Any time you return a function value, or otherwise keep it around for longer than the lifetime of the function activation in which it is activated, any free local variables in the closure which are captured by the containing environment must refer to locations on the heap. (Copying them by-value breaks the semantics of closures.) This conflicts with the assumption in C++ that auto variables local to a function activation are part of the function's activation record on the stack.

You could get around this problem with spaghetti stacks or something, but you'd need to find a way to free the activation records that are floating around after their enclosing scopes have expired -- enter garbage collection which you do NOT want to require for C++.

That's the problem with Lisp, it's almost all-or-nothing. If you want to correctly include some of the benefits of the Lisp execution model -- like lambdas -- you need to accept the whole thing, lock, stock, and barrel. Including heap-allocated local vars and the garbage collector. (And yes -- Python, Ruby, Haskell, and Standard ML have a "Lisp execution model" in this sense.)

So we get compromises and hulking abominations like C++0x lambdas or -- worse yet -- their predecessor, Boost Lambdas.

tl;dr: Upward funargs are hard, let's go shopping.