§6.6 Modular Composition: bind merge semantics when host targets a $ref'd path

[mkalish]

Context

I'm prototyping a workflow-orchestration spec (FlowSpec) whose data model is a composed FormSpec — a public applicant-facing intake form combined with internal context sections (AI extractions, fetched data, computed fields, adjudicator decisions). Working through §6.6 to split a single-document FormSpec into a base + composed pair, I hit an ambiguity I can't resolve from the spec text.

The ambiguity

§6.6.2 rule 3 says binds from a $ref'd Definition are imported into the host. It doesn't specify what happens when the host's own binds array targets a path imported from the base.

Concrete case. Base form (pfml-applicant-form|2026.1.0) declares:

{ "path": "applicant.ssn", "required": "true",
  "constraint": "matches($, '^[0-9]{3}-[0-9]{2}-[0-9]{4}$')" }

Composed form $refs the base's applicant group by fragment, then in its own binds array adds:

{ "path": "applicant.ssn",
  "relevant": "$workflowStage = 'intake'" }

After assembly, what is the effective bind on applicant.ssn?

1. MIPs merged per property — the path ends up with required, constraint, AND relevant from both sources. (Most useful; matches the mental model of "the host adds workflow-context behavior on top of base validation.")
2. Last-write-wins / first-wins — only one bind survives.
3. Definition error — duplicate binds at the same path are forbidden, even after assembly.
4. Undefined / implementation-specific.

§4.3 describes individual MIP properties but never addresses multiple binds targeting the same path. §6.6.2 rule 3 says "Their paths and scopes MUST be rewritten" but is silent on conflict resolution.

Why it matters

The answer determines whether the "extend a published base Definition" pattern is feasible at all:

• If MIPs merge (case 1), composition genuinely supports adding workflow-context behavior to a published applicant form without forking it.
• If last-wins or error (cases 2–3), every composed Definition has to either avoid touching base paths or fork the base form.
• Different implementations could land on different answers without normative guidance, breaking portability.

What would help

A normative paragraph in §4.3 or §6.6.2 specifying conflict resolution. My preference would be MIP-property merging — it's the only option that makes the pattern compose cleanly — but the priority is having an answer in the spec rather than which answer.