The mock Flang driver is only active in bootstrapping builds, and bootstrapping builds circumvent the FlangRTIntrospection.cmake by providing its result directly: llvm-project/llvm/runtimes/CMakeLists.txt at f0ca72c6f4e177f735e6486f839acb296c4d02f0 · llvm/llvm-project · GitHub (this was necessary even before the mock flang because even the real flang cannot compile the test program without the intrinsic modules)
selected_real_kind is derived from TargetCharacteristics which currently does not take into account whether REAL(10)/REAL(16) are available: llvm-project/flang/include/flang/Common/type-kinds.h at 6befe13812e6b5706aaf67c7dda0ba814464d1fe · llvm/llvm-project · GitHub. I think this is just a bug.
How I would do it, the pragmatic approach: Enable Flang’s support for REAL(16) depending on backend support, as discussed.
On the Flang-RT side, the modules can only be compiled with full flang, so either use the preprocessor as it is know to hardcode REAL support depending on architecture, or make flang define another preprocessor symbol depending on whether the backend reported REAL(16)/REAL(10) is available. For PPC, additional modules are enabled, but it is hardcoded depending on the triple: llvm-project/flang-rt/lib/runtime/CMakeLists.txt at 12628715ce61c8db841211eb8683e2f53fa74f0b · llvm/llvm-project · GitHub. There is no such configure-time dependency for quadmath yet, and if there was, I would also just make it depend on the triple.
For quadmath trancedental functions, compile them whenever the C++ compiler can compile them. It does not matter if they exist even though Flang never generates code for them. The other way around we cannot avoid anyway, and the same could happen for libgcc/compiler-rt as well (libatomic is optional, and there is no mechanism the disables atomics in Clang if libatomic is not available; you get a linker error).