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-
note-1]


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.