G.5:10 - Rationale

• Why registries? Reusable method-family dispatch requires stable, auditable row editions with explicit eligibility and assurance records, so later uses can recover the grouping and its dispatch basis.
• Why separation via Extensions? QD, OEE, preference-learning, and similar families are fast-moving and method-specific; making them part of the selector head would force a universal semantics and violate strict distinction.
• Why set-return? Partial orders are common and often the only admissible representation under heterogeneous scales; set-return preserves semantics and makes tie criteria explicit.
• Why explicit defaults with one declared source? Defaults are unavoidable; single-source indexing prevents competing defaults from silently diverging across patterns.
• Why selected-set result declaration here? Once the current question is to state retained alternatives or an all-member result for downstream use, the selector should declare that result directly instead of leaving it implicit in local choice, pool-policy, or enactment notes written for other purposes.
• Why JointUseSet? A shortlist preserves alternatives for later choice; an all-member result says that removing one member changes the result for the named use. G.5 mints JointUseSet only as a local SetResultFamily value and reuses the existing outcome schema and member identities. G.5-3 Select may emit it only over exact Method candidates admitted through that kernel; G.5-6 DeclareSetResult covers exact already grounded members without retyping them as Methods. Neither branch mints a new U-kind, Method kind, relation kind, or registry kind. CoUseSet is less plain, ComplementarySet would imply a relation among the members, and Bundle would misname a package form.