Function resolve_name_layered 

pub fn resolve_name_layered<'a, 'b, A, F>(
    source: &str,
    node_name: &str,
    namespace: &str,
    authoritative: A,
    fallback: F,
) -> Result<ResolvedName, ()>
where
    A: IntoIterator<Item = (&'a str, &'a str)>,
    F: IntoIterator<Item = (&'b str, &'b str)>,

resolve_name with the rules split into two PROVENANCE TIERS: every authoritative rule is consulted before any fallback rule, whatever order either was declared in.

Why a tier and not a field on the rule

A remap’s provenance only ever decides one thing — which rule wins when two channels name the same entity — and the tree has no single rule TYPE to hang it on: the C and C++ roads store executor::spin::RemapRule, the Rust road stores a bare &[(&str, &str)] on RuntimeCtx. The one thing both roads share is this function, so the tier is an ARGUMENT here rather than a field there. That also makes the guarantee structural instead of documentary: a caller cannot promote a fallback rule by declaring it first, because the two tiers are different parameters and the loop below can never interleave them.

The rule this encodes

Launch is authoritative; anything else is a fallback for a name the launch projected no rule for. That is RFC-0046’s precedence for node identity (launch overrides the code-provided default) applied to the remap half of the same question, and it is rcl’s own arrangement: rcl_remap_topic_name checks the node’s LOCAL arguments (how a launch file or component container hands a node its rules) and only on no match the process’s GLOBAL ones (the argv given to rcl_init) — Humble rcl/remap.h.

The producers: both roads pass their codegen-projected launch rules as authoritative; the fallback is the --ros-args parse (crate::ros_args), which nros::init_with_args carries on its Context into every executor that context creates.