Morgan :)

> The only real requirement is that if the annotation is public, the macro implementation must also be public. They could come from different packages though and imo that would...

> > I think that's fine? Macros can evolve their annotations carefully, and give careful version constraints implementation->annotation, which we need to respect when fetching the implementation. Because the macros...

> Ok I think maybe it would be helpful to get a bit more concrete, I think I see what you are getting at, so here is a proposal based...

> > I would punt on this for now--just treat the implied or explicit macro_dependencies as normal dependencies and do one version solve as we do today. Then we only...

> * a binary dependency is a dependency for client packages, but does not as dependencies on its dependencies, and did not provide its own content as `package:` accessible code....

A minor question came up in discussion with Jake today: do we allow multiple macro implementations to be associated with one annotation; and if so, what order do they run...

Good point, thanks, it's anyway a goal that macros are easily to compose in code, there is perhaps no use case left for combining them declaratively.

I have been prototyping in this area and should have some results to share soon.

https://github.com/dart-lang/language/tree/main/working/macros/dart_model now has some runnable macros using a query approach, plus a guide to setting up a huge example to see how it fares from a performance point of view.

Some notes on that huge example performance here https://github.com/dart-lang/sdk/issues/55784#issuecomment-2141636339