This leads me to think that this isn't such a great problem after all, because when the problem is reduced to this point, one "solution" could simply be to say that compile-time code is always interpreted. With that limitation, it's easy to give all compile- time instances of modules a separate namespace from the run-time instances, because the code is re-loaded and hygienified (which is where namespaces are chosen) every time anyways.
Loading interpreted code is significantly slower than loading compiled code, but in practise I find that macros rarely use very many libraries. Obviously it would be even cooler to have real compiled macros, but I think it's not as important as having a correct and working solution.
Hmm.. When thinking about this some more, maybe pure interpretation isn't such a great solution after all. I can imagine a couple of cases where this would assume something similar to an exponential behavior (I haven't thought about this very closely).
It might be possible to work around that by caching half-compiled (that is, fully macro-expanded) code. This would benefit performance for other situations as well, in particular interactive development where the interpreter's debugging features are desired. I wonder if this can be done completely transparently to the user or if it's too complex to be a good solution.
But I still don't see any error in the main point of my previous mail, that is that only two different sets of globals are needed.
/Per
(Sorry for double post, Marc)