coverage: 94.977%. remained the same — sh3xu:feat/types-resource-namespace-map-2409 into i18next:master

@adrai I tried the exact setup (shared_conflict: 'A' in legacy and 'B' in registry, then t('shared_conflict') on TFunction<'overlap'>).
What I found is _MergedResources itself seems to be doing the right thing ('A' & 'B' -> never). The issue starts a bit later during key building. KeysBuilderWithoutReturnObjects sees never, goes down the object path, ends up in keyof never, and TS kind of spirals from there with the "Type instantiation is excessively deep" error.
So it doesn't really fail only on that conflicting key one conflicting overlap entry ends up blowing up the broader t() inference.

@sh3xu great catch — I reproduced your finding locally, dug into why it happens, and have a verified fix below. You weren't imagining it: the conflict scenario does break the whole t() signature, not just the conflicting key.

Root cause — two TS quirks compound

Quirk 1: L & R collapses to never when any property's literals conflict.

type A = { x: 'A'; y: 'common' };
type B = { x: 'B'; z: 'beta' };
type AB = A & B;
//   ^? never (NOT { x: never; y: 'common'; z: 'beta' })

This means a single same-key/different-literal disagreement (shared_conflict: 'A' vs 'B') annihilates the entire overlap namespace — legacy_only, registry_only, shared_literal all vanish.

Quirk 2: KeysBuilder recurses into never, and keyof never is string | number | symbol.

Once a resource value becomes never, the key builder in t.d.ts tries to walk it. keyof never is string | number | symbol (not never), so the recursion explodes into "Type instantiation is excessively deep". That poisons t() overload resolution for every namespace in the program — exactly what you saw with @repo/ui falling back to the TemplateStringsArray overload.

Fix (two parts, both required)

1. typescript/options.d.ts — per-property merge with conflict filtering

Replace the naive _LegacyResources & ResourceNamespaceMap with a structural per-property merge, then drop never-valued keys with Pick:

type _LegacyResources = CustomTypeOptions extends { resources: infer R } ? R : object;

// Per-property merge of two object types. Unlike `L & R`, which TypeScript
// collapses to `never` whenever ANY property has incompatible literals (so a
// single same-key/different-literal conflict wipes out the whole namespace),
// this iterates keys and intersects them individually — the conflicting key
// becomes `never`, the rest survive.
type _PerPropMerge<L, R> = {
  [K in keyof L | keyof R]: K extends keyof L
    ? K extends keyof R
      ? L[K] & R[K]
      : L[K]
    : K extends keyof R
      ? R[K]
      : never;
};

// Drop properties whose value resolved to `never`. Without this, the
// conflict key would leak into `keyof Resources[ns]`, then poison
// `KeysBuilder` recursion (it tries to walk a `never` value) and break
// `t()` overload resolution for the entire namespace.
// NOTE: must use the `Pick<T, NonNeverKeys>` form. A `[K in keyof T as ...]`
// remap does NOT eagerly evaluate `T[K]` for intersection types, so conflict
// keys would survive the filter.
type _NonNeverKeys<T> = {
  [K in keyof T]: [T[K]] extends [never] ? never : K;
}[keyof T];
type _DropConflictKeys<T> = Pick<T, _NonNeverKeys<T>>;

// When the same namespace exists on both sides, deep-merge per property and
// strip same-key/different-literal conflicts. Otherwise pick from whichever
// side has it.
type _MergeNamespaces<L, R> = {
  [K in keyof L | keyof R]: K extends keyof L
    ? K extends keyof R
      ? _DropConflictKeys<_PerPropMerge<L[K], R[K]>>
      : L[K]
    : K extends keyof R
      ? R[K]
      : never;
};

type _MergedResources = [keyof _LegacyResources] extends [never]
  ? [keyof ResourceNamespaceMap] extends [never]
    ? object
    : ResourceNamespaceMap
  : [keyof ResourceNamespaceMap] extends [never]
    ? _LegacyResources
    : _MergeNamespaces<_LegacyResources, ResourceNamespaceMap>;

2. typescript/t.d.ts — defensive [Res] extends [never] guards on the key builders

Defense-in-depth so any case (including deeply nested conflicts) that reaches the key builder doesn't spiral:

type KeysBuilderWithReturnObjects<Res, Key = keyof Res> = [Res] extends [never]
  ? never
  : Key extends keyof Res
    ? Res[Key] extends $Dictionary | readonly unknown[]
      ?
          | JoinKeys<Key, WithOrWithoutPlural<keyof $OmitArrayKeys<Res[Key]>>>
          | JoinKeys<Key, KeysBuilderWithReturnObjects<Res[Key]>>
      : never
    : never;

type KeysBuilderWithoutReturnObjects<Res, Key = keyof $OmitArrayKeys<Res>> = [Res] extends [never]
  ? never
  : Key extends keyof Res
    ? Res[Key] extends $Dictionary | readonly unknown[]
      ? JoinKeys<Key, KeysBuilderWithoutReturnObjects<Res[Key]>>
      : Key
    : never;

3. Update the tests to exercise the conflict integration path

In test/typescript/registry-monorepo/package-app-legacy.d.ts, add to overlap:

shared_conflict: 'A';

In test/typescript/registry-monorepo/package-overlap.d.ts, add to overlap:

shared_conflict: 'B';

In test/typescript/registry-monorepo/t.test.ts, replace the existing synthetic conflict test with a real integration assertion:

it('drops same-key/different-literal conflicts from the merged namespace', () => {
  // `shared_conflict` is 'A' in legacy and 'B' in registry. Without
  // filtering, the entire `overlap` namespace would collapse to `never`
  // (TS reduces `{ x:'A' } & { x:'B' }` to `never`) and poison `t()`
  // overload resolution.
  // @ts-expect-error 'shared_conflict' is dropped because legacy says 'A', registry says 'B'
  assertType(t('shared_conflict'));
});

Verified locally

• All 14 registry-monorepo tests pass with the conflict in place.
• Full TS suite: 480 tests pass, zero type errors, no regressions.

TS quirks worth a comment near the code

Both were non-obvious enough that I'd recommend leaving the inline comments above as-is — they document why each piece looks the way it does:

• [T[K]] extends [never] only triggers when TS forces evaluation of the intersection. In a key remap ([K in keyof T as ...]), the check is deferred and doesn't fire. The Pick<T, NonNeverKeys> form forces it.
• keyof never is string | number | symbol, which is why the recursion guard is essential.

Happy to push these changes if you'd prefer — maintainerCanModify is on. Otherwise feel free to apply directly.

Just noticed you pushed updates — thanks for the quick turnaround. Verified locally:

• Fix applied verbatim in options.d.ts and t.d.ts ✓
• Expanded HACK: comment + clarified ResourceNamespaceMap JSDoc ✓
• Conflict integration test in place (shared_conflict: 'A' vs 'B') ✓
• Bonus: selector-mode coverage via the separate tsconfig.selector.json compile unit. Choosing enableSelector: true over 'optimize' actually exercises the type machinery more thoroughly than I'd suggested — nice call.

Full TS suite: 496 tests pass, zero type errors, no regressions.

Looks good from my side. Are you happy with where it is, or is there anything else you'd like to try before we merge?

@adrai Happy with it as is from my side thanks again for validating everything locally.

Nothing else I'd push for before merge. If theres any edge case or additional coverage you think would be valuable here though, I’d be interested to hear your take always useful stuff to learn from.

thx a lot... it's included in v26.3.0