This is a perfect example of why digging into specific, concrete examples is absolutely vital for a proposal like this: overly abstract arguments can be plausibly pointed in any direction. To me, the proc macro API (plus the de facto standard syn and quote crates) already provide the decoupling intermediary we need for compile-time reflection. So without any further details, the fact that diesel has its own proc macro doesn't seem any more problematic than the fact that diesel would have its own reflection function you'd have to invoke if it used runtime reflection instead.
Bringing up aspect-oriented programming was probably the most concrete thing I did see. Although I have only a vague awareness of AoP, the people I've talked to who've used it mostly provide stories of incomprehensible configuration regularly leading to indecipherable startup errors. In contrast, your posts appear to be suggesting that not supporting AoP is a serious design flaw of the language. I don't know who's right, but if the utility of this feature proposal rests on AoP use cases, there definitely needs to be some effort spent fleshing out the AoP use cases that you want Rust to support, for those of us who aren't already familiar with and supportive of them.
(you mention a "provided example" in your post, but unfortunately I have no idea what this is referring to; I only see a reflection API sketch in the OP)
It's probably worth noting that "reflection" plus "safety guarantees and performance" is almost certainly going to end up meaning compile-time reflection instead of runtime reflection. After all, most of Rust's magic is compile-time magic; at runtime it's doing the same stuff as every other AoT-compiled language (except the "pull-based" futures I guess?).
AFAIK, the major "other languages" that use runtime reflection today do so not because there are any use cases where runtime is better, but either because they don't have a compile time at all, or because they prioritize flexibility over performance, or because they're managed languages which already have other reasons for paying the price of keeping type metadata around at runtime, so "just" exposing it to the language isn't as big of a deal. Is that not true for whatever language you're thinking of?