Thanks for the detailed explanation of the problem you are trying to solve.
One of the design goals of ROS 2 is to be transport-agnostic. While we recommend and use DDS as the default transport layer, there are also alternate transports in use (some examples here).
Every time we expose a DDS feature through the RMW interface, this causes additional work for the non-DDS RMWs. So we have tried to carefully choose what is exposed through the RMW.
The other reason we have been cautious about exposing all of the DDS features is to avoid overwhelming users with too many choices about their transport. As we’ve discussed elsewhere, most of our users want to work on robotics, not on transports. They expect the transport to work reasonably well “out-of-the-box” as much as possible.
Neither of those reasons mean we can’t expose new DDS features, but that we need to carefully consider the impact of doing so.
I will also point out that there is another alternative here. It is possible to “side-load” some DDS features into the DDS implementation of your choice (see <no title> for some examples). The method currently varies between DDS vendors, and there are some caveats to doing so, but it allows a way to go around the more limited ROS 2 RMW API. We’ve had some interest in standardizing this, but there hasn’t really been much work done along these lines yet: Add design document on configuring QoS at startup time · Issue #280 · ros2/design · GitHub.