I understand what you mean, but I am not sure I agree. As a macro writer i either want to depend on the local definition explicitly (using datum->syntax in synt

I understand what you mean, but I am not sure I agree. As a macro writer i either want to depend on the local definition explicitly (using datum->syntax in syntax case or not renaming in an er-macro-transformer). I also don't want to accidentally alter behaviour of macros if I happen to shadow a binding. I have made a version of racket's for loops that depends on expansion to other macros (to be able to split the complexity in smaller chunks). Having that expand unhygienically would open the macro up to subtle errors. I also don't have to re-export bindings that I happen to use (like a specialised let from srfi-71 that supports multiple return values) and not changing let for whoever imports my library or polluting their namespace. Expanding the macro in guile makes it clear in the generated code where things come from a (let ...) in the generated code gets expanded to ((@@ (loops for-loops) let) ...), Which is easily debuggable. I just don't happen to see what you are describing about hygiene as a problem. It is the behaviour I want as a macro writer and the vast majority of time as a macro user. The only big problems with it are 1. The Implementation sucks. The concepts are quite easy to grook, but hard to implement. 2. The hygiene has some edge cases where it might not protect you if you are writing very complex macros gluing quoted syntax objects together.