It is not just a question of state. Each instance of a module must go through an initialization phase (i.e. the phase when the "define"s and the top-level expressions of the module are executed). What if a module contains this definition
(define start-time (current-time))
or
(define unique-id (random-integer 1000000000000000))
or
(define t (thread-start! (make-thread (lambda () ...))))
or
(define v (list 1 2 3))
In all of these cases it may be important to run the initialization phase for each instance of the module, to get a correct start-time of the instance, a unique identifier for that instance, a thread per instance, or unique objects for each instance (to distinguish them with eq?).
Globals also give rise to another kind of problem in module systems. What should happen when re-importing a module? Should the globals be wiped? Depending on what they contain, often that is not desirable. What I have done so far is simply to not use them. This is of course less powerful than having them, but it also yields nicer programs most of the time. I still don't know how I think globals are best implemented, from this perspective. Here I don't see a pure and difficult vs. simple but incorrect situation. /Per