Context
PR #63 legalized case-distinct tokens for explicitly case-sensitive options (pairwise collision rule) and made per-entry case-sensitivity overrides settable. Execution, parsing, and suggestion (KnownTokens, now ordinal) honor the per-entry sensitivity, but several discovery surfaces still dedupe tokens with a case-insensitive or global-derived comparer, so a valid declared token can be omitted from display:
HelpTextBuilder.Rendering.BuildOptionRow — visibleTokens uses Distinct(StringComparer.OrdinalIgnoreCase) (within-row alias loss for case-variant aliases of one option).DocumentationEngine.BuildDocumentationOption* — aliases/reverse aliases/value aliases deduped OrdinalIgnoreCase (4 sites).AutocompleteEngine.CollectOptionAutocompleteCandidates — dedupe HashSet seeded from the GLOBAL comparer, so under a case-insensitive global one of two case-sensitive twins is dropped from the interactive menu.ShellCompletionEngine — the shared dedupe set (line ~51) is OrdinalIgnoreCase and spans several candidate kinds (route literals, option tokens, values), so the fix must be scoped per kind to avoid changing command-literal dedupe.
Suggested direction
Mirror the pairwise collision rule: collapse two tokens only when ordinal-equal, or when case-variant AND both entries effectively case-insensitive. For within-row help/doc dedupe, plain ordinal is likely sufficient (declared tokens of one option). The shell shared set needs a per-kind split before its comparer can change.
Origin
Flagged by codex review on PR #63 (comment r3590334801). Deferred: discovery-only impact, in an exotic configuration, while the runtime paths are already consistent — and the shell shared-dedupe change carries cross-kind risk that deserves its own tests.
Context
PR #63 legalized case-distinct tokens for explicitly case-sensitive options (pairwise collision rule) and made per-entry case-sensitivity overrides settable. Execution, parsing, and suggestion (
KnownTokens, now ordinal) honor the per-entry sensitivity, but several discovery surfaces still dedupe tokens with a case-insensitive or global-derived comparer, so a valid declared token can be omitted from display:HelpTextBuilder.Rendering.BuildOptionRow—visibleTokensusesDistinct(StringComparer.OrdinalIgnoreCase)(within-row alias loss for case-variant aliases of one option).DocumentationEngine.BuildDocumentationOption*— aliases/reverse aliases/value aliases dedupedOrdinalIgnoreCase(4 sites).AutocompleteEngine.CollectOptionAutocompleteCandidates— dedupeHashSetseeded from the GLOBAL comparer, so under a case-insensitive global one of two case-sensitive twins is dropped from the interactive menu.ShellCompletionEngine— the shareddedupeset (line ~51) isOrdinalIgnoreCaseand spans several candidate kinds (route literals, option tokens, values), so the fix must be scoped per kind to avoid changing command-literal dedupe.Suggested direction
Mirror the pairwise collision rule: collapse two tokens only when ordinal-equal, or when case-variant AND both entries effectively case-insensitive. For within-row help/doc dedupe, plain ordinal is likely sufficient (declared tokens of one option). The shell shared set needs a per-kind split before its comparer can change.
Origin
Flagged by codex review on PR #63 (comment r3590334801). Deferred: discovery-only impact, in an exotic configuration, while the runtime paths are already consistent — and the shell shared-dedupe change carries cross-kind risk that deserves its own tests.