Function rmw_selector 

pub fn rmw_selector() -> Option<String<RMW_SELECTOR_CAP>>

The answer to “which RMW backend did the user select” — one reader, one semantic, for every consumer.

phase-359 W10 / issue 0687. This variable had FOUR readers with THREE semantics: Executor::open read it as raw OS bytes, nros’s open_session as a UTF-8 string filtered for empty, nros-c’s entry as a string passed through EVEN WHEN EMPTY, and nros::init as a string with an RMW_IMPLEMENTATION fallback the other three did not have. “Which backend did the user ask for” had four answers in one process.

Two decisions are baked in, and both are deliberate:

• $NROS_RMW only. $RMW_IMPLEMENTATION is NOT folded in, though it was tempting and one reader did it. The two carry different vocabularies: this selector is matched against the cffi registry’s canonical names (zenoh, dds, cyclonedds), while RMW_IMPLEMENTATION holds ROS names (rmw_cyclonedds_cpp). Feeding a ROS name to resolve_backend yields Unknown — an ERROR — where today it is ignored and the unique-backend path runs. Unifying them without a mapping would convert “ignored” into “fails to start”. crate::init keeps its fallback for the Context.rmw HINT, which is a different quantity.
• Empty or non-UTF-8 means unset. A name that is not UTF-8 cannot match a registry entry, so treating it as absent is what the caller wants; the old raw-bytes reader would have reported Unknown instead.

The return is heapless::String rather than String because RMW_SELECTOR_CAP is a real bound, not a guess: it is the capacity of Executor::primary_rmw_name, so a longer value cannot name a registry slot and is reported as unset rather than truncated into a different backend’s name.