The question is a good one, and I am curious too, but this is a bad example as the practice of shading the Kotlin runtime for a library like this leads to unnecessary duplication since it’s a runtime that may often be shared by end user code anyways. If there were backwards compat problems w/ Kotlin runtime or you had to have a single-JAR-but-scared-of-classpath situation it might be different, but in general I would avoid it.
I wonder this too. From my naive reading of the link you have, the metadata lib mutation readme, and the metadata protobuf they embed I would guess there is some non-trivial work to refactor and change the compiled package name. Things get even more complicated w/ JvmPackageName attributes and what not.
I’d say if you don’t end up getting a satisfactory answer, do some tests and make sure some of those test cases exercise Kotlin-only reflection too (e.g. KClass.qualifiedName). I would guess that, unless you use Kotlin reflection specifically (i.e. no reflection or Java-only reflection is fine), you could probably use maven-shade, shadow, or whatever. Worst case scenario, you may end up doing source-level refactorings which sounds like a nightmare.