Under “No RTTI” guarantees it says:
Pursued. Many SG14 companies compile with
RTTI turned off but might still want to use
PMR allocators; however, some
implementations use dynamic_cast in their
PMR types. Offering PMR with a “no-RTTI”
guarantee, or at least a compile-time
checkable guarantee would be desirable.
Consider eliminating note [mem.res.private-
This is completely QoI. The standard doesn't require dynamic_cast there, and the note is talking about derived memory resources, possibly in the user's own code. It's just suggesting an optional optimization, which isn't needed at all, and can be made conditional on RTTI being enabled.
If your implementation uses dynamic_cast unconditionally, complain to your vendor. They should do it conditionally, based on the __cpp_rtti feature test macro. That will work perfectly well with -fno-rtti or the equivalent.
In any case, the only use of dynamic_cast I can find in any implementation of PMR is in GCC's experimental::resource_adaptor which already uses __cpp_rtti (and isn't in the standard yet, just a TS). Maybe the request should be considered for that type, as proposed for C++26 by P1083, but even there, I consider it completely QoI.