When a load table's overlay match point targets a repeatable field such as the 019 (OCLC number cross-reference), the load process only compares the first subfield occurrence against Sierra's index. Although Sierra correctly indexes every $a in the 019 individually, the overlay-match routine stops after the first $a. Any additional OCLC numbers stored in the second, third, or subsequent $a subfields are ignored when determining whether an incoming record should overlay an existing one.

As a result, records that should match an existing bib overlay as new duplicates instead, because the matching value lives in a $a other than the first.

Use case:
OCLC regularly merges master records and moves superseded control numbers into the 019 field. A single existing bib may legitimately carry several OCLC numbers — one current number in the 035/001 and one or more prior numbers in repeating 019 $a subfields. When we receive an incoming record whose control number matches any of those values, we want it to overlay the existing record rather than create a duplicate. Today that only works if the match happens to fall on the first 019 $a.

Libraries running lean cataloging operations — including those that have lost cataloger positions and rely more heavily on automated overlay logic — are especially exposed to the duplicate records this creates.

Requested behavior:
When an overlay match point (@ov_tag) references a repeatable field, the load process should iterate through all subfield occurrences of that field and test each against the corresponding Sierra index. A match on any occurrence should trigger overlay, consistent with how Sierra already indexes each occurrence.

Impact if implemented:
Fewer duplicate bib records, less manual dedup/cleanup, and overlay behavior that matches the indexing Sierra already performs — a meaningful gain for libraries with reduced cataloging staff.