Trouble understanding define (!)

[Neil Jerram <neil at ossau dot uklinux dot net>]

I have just realized that I don't really understand how define works -
or is intended to work - when modules are involved.  (NB - I am
interested in the answers for the new (soon-to-be) module system, not
the current one, and in the theory, so "try it and find out" is not
really a sufficient answer!)

In the absence of modules, R5RS says that a top-level define should

- bind the symbol to a new location, if the symbol is currently
  unbound

- set the value of the symbol's existing location, if the symbol is
  already bound.

That seems clear enough, but what about an existing binding that is
imported from another module?

For example,

mymod.scm:
(define-public a 3)

guile> (use-modules (mymod))

Does the guile repl environment now contain a reference to mymod's
environment (i), or are mymod's bindings copied into the guile repl
environment?  If the latter, does the binding in the guile repl
environment point to the same vcell as the binding in the mymod
environment (ii), or to a copy of the vcell (iii)?

guile> (define a 5)

I think that what happens here is mostly determined by a combination
of R5RS and the answer to the previous question.

(i) => I'm not sure.  Could create a new binding in guile repl that
then shadows the one via the reference to the mymod environment, or
could set the value of the vcell of the binding that is looked up via
the reference to mymod.

(ii) => Sets the value of the shared vcell, affecting the perceived
value of a in both guile repl and mymod environments.

(iii) => Sets the value of guile repl environment vcell; does not
affect perceived value of a in mymod environment.

I presume that the difference between (ii) and (iii) would be
important if mymod also exported a procedure that used a as a free
variable:

mymod.scm:
(define-public (get-a) a)

guile> (get-a) => ???

Finally, what happens when you ...

guile> (undefine a)

Just from writing all this down, it seems clear that the answer cannot
be (ii), since that could be too damaging to the integrity of a
module.

Apologies if the answers can in fact be deduced from env.texi; my
impression was that they cannot.  env.texi is completely precise as
regards the behaviour of environment objects, but does not specify how
any given module implementation should use them.

    Neil