Note that what I'm talking about is perfectly doable without any runtime reflection at all, only through static compile-time reflection. E.g. attributes in c++

Note that what I'm talking about is perfectly doable without any runtime reflection at all, only through static compile-time reflection. E.g. attributes in c++ are a purely compile-time thing - if there was an API to do stuff with them it would also be a compile-time one. The code isn't meaningfully different though. But yeah, "fully automated build step" generally looks like "let's parse enough of the language so that we can implement our own custom reflection system" which leads to every project having an incompatible one and in practice much more pain (and macros) for the developers than if it was a standard one, e.g. Qt, Unreal Engine and so many others have their custom homegrown reflection scheme and there are a thousand libs on GitHub trying to reimplement it: https://github.com/topics/reflection?l=c%2B%2B https://github.com/topics/reflection?l=c%2B%2B It's exactly like type systems being Turing complete : if yours isn't, someone somewhere will be making a language that compiles down to yours with one because of how useful of a property it can be in some cases. All of this is not accidental complexity, the alternative to not having them is much, much, much less productive in practice. My personal experience writing code with reflection is that at the cost of one complicated base library, the app code is literally 10x faster and simpler to write, and the huge majority of the time is spent in app code, not library one.