Macros, as in macro_rules!, work perfectly cross-editoin. Edition is checked per-span, so the same as other hygeine.
The problem with code generation is when you can’t attach span information. This applies both to proc-macros (which only have call-site hygeine currently, and will be solved when def-site hygeine is usable) and especially for generated-for-include! code, which doesn’t currently have any way to provide span information.
The potential for #[edition = "2018"] { .. } depends entirely on when during parsing/processing it would need to happen. The tracked-edition-by-span means that the post-parse architecture exists already, it’s just the complexity of generating the parse tree. Keywords differing between editions makes me fear that this anotation would have to be handled in the parser directly. (But it could be.)
The current position seems to be that it should always be possible to generate code that compiles without warnings in all editions you can support (cc @steveklabnik).
I think that the ideal end-state solution is compile-to-Rust-TokenStream. If the build.rs steps can generate TokenStreams with correct Span information (including at least edition, and ideally the ability to point into other files), the problem disappears and code (pre) generation gains the superpowers of procedural macros. (This will require some way to serialize TokenStream with Span information if it wants to persist across compiles rather than doing the generation work every time.)