In PyArc, right now, we just re-parse and re-eval it, so loading the same module twice is not a problem.
Okay, so, I fixed the issue with it thinking a variable was undefined when it wasn't. I then found out something very interesting:
; foo.arc
(assign message* "hello")
(mac ret () 'message*)
; bar.arc
(import foo "foo.arc")
(foo!ret) -> "hello"
(= ret foo!ret)
(ret) -> error: message* is undefined
So... without even trying to, I automagically made macros sorta-hygienic with modules. When you import a module, and then call it's macros using the foo!bar table convention, it works just fine. The macro will use it's defining environment, rather than the caller's environment. But... if you pull the macro into the current namespace, it dies, because it's now being eval'd in the caller's namespace.
I'm pretty okay with this. It's kind of a wart that macros don't work quite right in that situation, but the fact that they do work when using the table is pretty darn nice. This also theoretically gives the caller the choice of whether to eval the macro in the defined environment, or the caller environment. The only issue, I think, is that this behavior may be confusing, at least until you've been bitten by it once or twice; by then you should have it memorized. :P
Obviously this is just a simple test... the real test will be when it's released and we'll have more complicated macros. Then we'll see if there's still any major hygiene problems or not.
