Scope refers to where a binding can be accessed. Indefinitely scoped variables can be seen from anywhere in the program. My understanding of that is that in effect, there's only one dynamic scope. It may or may not override the current lexical scope, and there may be a mechanism to shadow and unshadow variables as they come in and out of extent. But it shouldn't make a difference where in the source code a binding is made. So I would expect your first example in that post to give 3, if define creates indefinite scope.
Extent refers to when it can be referenced. Dynamic extent means that once the binding has been unmade, the variable is no longer available.
> (define bar nil)
> (let ()
> (define foo 1)
> (set! bar (lambda (n) (+ foo n))))
> (bar 2) ; => 3
> foo ; error: unbound variable 'foo'
(Incidentally, if you (set! bar) before you (define foo), you get an error: bad define placement. I'm not sure what, if anything, that signifies, but it seemed interesting.)
ref: http://www.supelec.fr/docs/cltl/clm/node43.html
"in my example the two foo's could represent completely different memory locations and it would still work."
My understanding of closing is that once you create a lambda, it holds a reference to the lexical scope it was created in. You can modify that lexical scope and the lambda will still 'see' the changes, even if you were adding a new binding rather than just modifying an old one. So I don't see a conflict with define being lexical here.