You're not wrong, but I don't think this solves any of our problems here (since multiple macros would still share a single version) and it seems more like a bandaid to me.
Two dependency trees makes sense when they're actually inherently different, e.g. tools needed to develop your library that aren't necessary for clients, like a command plugin that lints your source code. Clients will never even build that code, so it would make sense to keep those dependencies separate. This was something previously discussed when plugins were proposed and I am not sure it was made clear that this only really achieves anything for command plugins since they're not part of the "regular" build at all.
Macros and build-tool plugins still need to be build by anyone using the library, whether it is the package author or clients, so we would only be solving a very narrow problem where all the macros and plugins happen to agree on a version, but the library code doesn't. That can be useful in some cases, but it seems too limited and hard to explain to make it worth the effort to me.
I think the real thing we would want is for every leaf of the dependency tree to have the potential for diverging dependencies, e.g. if you're building two independent libraries, there's no technical reason for them to share versions either. I don't think macros or host-side tools are special in any way here, definitely not in terms of the design and implementation. Unfortunately, this isn't how SwiftPM was originally designed -- the majority of its current architecture and implementation hinges on the fact that each package can only exist once in the dependency tree, all the way from dependency resolution down to the built products being intermingled in a single directory.
In the fullness of time, this is certainly a problem worth solving, but without presupposing a design, I cannot see a way to achieve anything here without a potentially multi-year effort. Practically speaking, I don't see an alternative to accepting this limitation as a given for the purpose of the discussion around macros.