Yeah, this is a great point. We're effectively exposing Swift's type system as an API for users, and it would be best if there could be a single type API that works for runtime reflection, macros, and Swift-based tools.
However, what would this mean for our design? Does the representation of a type need to be something that can be used with several different sources of information at once, i.e., can you get a type from reflection information (say, from a T.self in the running program) and pass that type to some static reflection facility (say, that looks at the binary for a library that hasn't been loaded) or ask the compiler for more information about it from the corresponding source code?
I think the best way to come at this problem is to separately design the type representation we'd want for macros and/or a compiler (I assume they'd be the same, but one never knows), and then do some compare/contrast to see what unification would look like. I suppose that's on me to peek further down the road of providing type information to macros.
Doug