Anonymous `:>>` redefinition of a multi-valued feature resolves to a sibling redefinition instead of the base feature

[mzargham]

Expected behavior

Each anonymous redefinition of a multi-valued feature should resolve redefinedFeature to the declared base feature, regardless of how many siblings redefine it. Given:

package Lib {
    part def Item { attribute name : String; }
    part def Container { ref part items : Item[*]; }
}

package Usage {
    private import Lib::*;
    part a : Item { :>> name = "a"; }
    part b : Item { :>> name = "b"; }
    part c : Container {
        ref :>> items = a;
        ref :>> items = b;
    }
}

Both ref :>> items = ... lines should redefine Container::items.

Observed behavior

check --strict accepts this (exit 0, no diagnostic). But convert --to compact-json shows each redefinition's redefinedFeature pointing at the other line, not at Container::items:

$ sysmlv2 convert lib.sysml usage-two-ok.sysml --to compact-json --lib sysml.library -o two.json

Redefinition edges in two.json (redefinedFeature <- redefiningFeature):
  f0c8e2d7… (2nd items-redefinition) <- 4fb2b636… (1st items-redefinition)
  4fb2b636… (1st items-redefinition) <- f0c8e2d7… (2nd items-redefinition)

Container::items's own element id (b7d7820c…) never appears as a redefinedFeature target anywhere in the file. The two redefinitions point at each other instead of the base feature, with no diagnostic.

Add a third redefinition and the same lookup now finds two sibling candidates instead of one, and reports it as ambiguous:

$ sysmlv2 check --lib sysml.library --strict lib.sysml usage-three-ambiguous.sysml
error: ambiguous reference `items` resolves to multiple memberships
  --> usage-three-ambiguous.sysml:7:11
   | 		ref :>> items = a;
error: ambiguous reference `items` resolves to multiple memberships
  --> usage-three-ambiguous.sysml:8:11
   | 		ref :>> items = b;
error: ambiguous reference `items` resolves to multiple memberships
  --> usage-three-ambiguous.sysml:9:11
   | 		ref :>> items = c2;
3 error(s)

convert's JSON confirms all three come back as an unresolved {"@ref": "items"} placeholder rather than a wrong-but-found element.

Suspected root cause

The lookup that resolves an anonymous redefinition's target name appears to register each anonymous redefinition under the name of the feature it redefines, within its own owning scope — so sibling redefinitions of the same base feature become visible to each other as candidates for that name, instead of the lookup resolving solely to the inherited base feature.

• At exactly one sibling, the lookup finds one (wrong) candidate → Found, silently mis-wired, no diagnostic.
• At two or more siblings, the lookup finds multiple candidates → Ambiguous, which is the reported error.

Analysis and evidence

OpenSysML was used as a second opinion on both cases:

Case	sysmlv2 check --strict	redefinedFeature actually resolves to (via convert --to compact-json)	OpenSysML -validate
2 anonymous redefinitions	✅ exit 0, no diagnostic	each other (sibling), never Container::items	✅ exit 0, resolves to Container::items
3 anonymous redefinitions	❌ exit 1, ambiguous reference 'items' ×3	unresolved ({"@ref": "items"}) for all three	✅ exit 0, resolves to Container::items

Full repro files, both tools' output, and the JSON evidence (element ids for both cases, plus the correctly-resolving :>> name = ... redefinitions shown for contrast) are in the linked gist.

Reproduce the JSON evidence directly:

sysmlv2 convert lib.sysml usage-two-ok.sysml --to compact-json --lib sysml.library -o two.json
python3 -c "
import json
for e in json.load(open('two.json')):
    if e['@type'] == 'Redefinition':
        print(e['redefinedFeature'], '<-', e['redefiningFeature'])
"

Link to gist

https://gist.github.com/mzargham/f8be45769a7ac851a54405a65d7e723b

[vincemolnar]

Name resolution must start in the specialized types and ignore the current namespace when resolving the target of a redefinition - this is the root cause.