I'm not sure if that level of complexity is truly necessary. I had a half-baked idea (OK, in all honesty, it was a mostly raw idea) that would simplify templating/runtime evaluation significantly from the end-user perspective. Using it, you could reduce the language size by turning all macros (including the magic ones) into procedural macros, and those would all be ordinary rust (no macro rules). The language itself would shrink, and more stuff would move into the rustc_interface crate. Since that is just a crate, we can do all the usual things of submodules, etc., which would mean that we could have an official core that all compilers support, then each compiler could have its own namespace (rustc_interface::core for everyone, rustc_interface::nightly for experiments, rustc_interface::gnu for gcc, etc.) 99.99% of all code would probably just stick with rustc_interface::prelude::*, which would only depend on rustc_interface::core, but if there is something that you absolutely need out of your compiler, and you don't mind that you can't use a different compiler, or need to do it a different way, then you can import the interfaces for the other compiler types.
My concern with C++ levels of complexity are the corner cases; unfortunately, it's been a number of years since I did C++ often enough to give you good examples, but I do remember skimming through the spec, and realizing that there were some really hairy cases that would require some hard work on the part of the compiler writer to get right. I want to avoid as many weird corner cases as possible.
I think I know what you're saying, but... procedural macros are turing complete, right? 