is: an ambiguous selector reports selector_not_found; RN text yields duplicate-label nodes

[thymikee]

Problem

is visible 'label="Catalog scroll: top"' fails on every run on the fixture Catalog screen (iOS Simulator, AX bridge), even on a fresh capture. get text with the same selector finds the element, and id="catalog-scroll-state" passes is visible.

Mechanism (from a live investigation on 2026-09-24, found alongside #2866/#2869):

• React Native exposes that text as a paragraph node plus a child node that carries the same label, so the label selector matches 2 nodes.
• is resolves through readUnique (packages/selectors/src/internal/resolution-policy.ts:68-71) and refuses a non-unique match. get text resolves through readText (:63-66), which picks one match, so it succeeds.
• is then reports the ambiguity as selector_not_found, which to an agent means the element does not exist.

Required behavior

• An ambiguous match on is returns a typed ambiguity outcome that names the match count, not selector_not_found. Key it on a typed reason, not on message text.
• Decide whether the duplicate RN text node (parent paragraph plus child with an identical label) should be one node in presentation. That would make label selectors on RN text unique, as they read to a user.

Evidence to reproduce

Open the fixture app's Catalog tab on an iOS 26.2 simulator. is visible 'label="Catalog scroll: top"' fails every time; get text with the same selector succeeds.

[MoogyG]

Another data point, on id= selectors and distinct elements rather than RN's duplicate text nodes.

Setup: Expo SDK app, iOS Simulator (iPhone 16, iOS 26.5), two sibling elements rendered with the same testID (so the same accessibility identifier).

0.21.15: all seven combinations I tried behave the same way. Those were Text+Text, Text+plain View, plain View+plain View, accessible View+Text, and a testID equal to the screen title, which collides with the NavigationBar identifier, against a Text, a plain View or an accessible View:

command	result
get text 'id="x"'	rc 0, text of one of the two, no warning
is exists 'id="x"'	rc 0
wait 'id="x"' 3000	rc 0
is visible 'id="x"'	rc 1, Selector did not match: id="x"
click 'id="x"'	rc 1, AMBIGUOUS_MATCH: Selector matched 2 distinct actionable elements

So click fails closed as intended (#1667). The reads, though, never surface the ambiguity: is visible reports it as a missing element (this issue), and get text, is exists and wait succeed on an arbitrary match. wait matters most in practice: an agent that waits on an ambiguous id before collecting evidence gets rc 0 and proceeds.

0.20.10 for comparison: the runner's preferHittableMatch read path raised AMBIGUOUS_MATCH for every command when both elements were accessibility elements, Text+Text included. When one was a plain View, every command, click included, silently acted on the other element (e.g. Tapped id="home" (197, 86) on the navigation bar).

Suggestion: it would help if the typed ambiguity outcome this issue asks for on is also covered get text, is exists and wait on a non-unique match. At minimum, the result could disclose the match count.