Difference in define behaviour between kawa.jar and embedded Scheme example

[Per Bothner]

In other words, the redefinition of + on the second line is affecting
the existing definition of six0 so that the applications of six0 and
six1 are both returning 9. What's going on here?

The behavior of demo0.scm depends on whether it is evaluated line-by-line
(as in REPL) or as a "module" (or "library" in R7RS-speak). The latter
is the default, but you can force teh former using the -f options.
Compare:
$ kawa demo0.scm
vs:
$ kawa -d demo0.scm

Either implicitly imports (kawa base). In general it is invalid to
explicitly define bindings that conflict with imported bindings.
We are somewhat more lenient with (kawa base), for compatibility
with tradition, but it is still a bad idea.

Instead you can do something like:

(import (except (kawa base) +))
(import (only (kawa base) (+ orig-+)))
(define (six0 x) (orig-+ 3 3))
(define (+ x y) (* x y))
(define (six1 x) (+ 3 3))
(format #t "[~w ~w]~%~!" (six0 0) (six1 0))

[Per Bothner]

OK, thanks. This is something I'm going to be looking into at the
source. As you know, I'm putting together a gratuitously incompatible
subset of the language, so I have no need for compatibility with
tradition. I'd rather get hard errors up front. To be honest, I'd
rather all redefines at the top-level be errors, but I assume this is
something I'm going to have to implement myself.

Re-definitions are not allowed in files (modules), but they are allowed
in line-by-line mode (a REPL or a file processed with -f).

I actually ran into this behaviour because I was informally testing my
subclasses of Scheme/SchemeCompilation and was surprised that I could
override existing bindings like this (because being able to affect the
internals of existing definitions wasn't the behaviour I was used to
from other Schemes).

Surely in most Schemes if f is implemented using gm and g is redefined,
then f will use the new definition (at least in a REPL)?