Multiple installed vue versions break ComponentCustomProperties template type-checking (nuxi typecheck) #1448

Environment

Reproduction

No isolated minimal repro yet — found in a real app (happy to build a minimal one if useful) — but the trigger and fix are fully bisected below.

Describe the bug

nuxt typecheck (vue-tsc) suddenly reported ~930 TS2339 errors across the whole app after a routine dependency bump, all of the same shape: any property added to <template> via ComponentCustomProperties module augmentation ($t from @nuxtjs/i18n, plus Nuxt/unimport auto-imported utils used only inside templates, e.g. our own goTo/formatDate) stopped being recognized:

error TS2339: Property '$t' does not exist on type '{ selectedEditionId: string | null; isLoading: boolean; ...; $nuxt: NuxtApp; }'.
error TS2339: Property 'goTo' does not exist on type '{ isLoading: boolean; ...; $nuxt: NuxtApp; }'.

Bisected the cause: our own package.json vue range moved from ^3.5.40 to ^3.5.41 in that bump. Before the bump, yarn.lock already had three distinct physical vue packages installed simultaneously (3.5.35, 3.5.39, 3.5.40 — pulled in via mismatched transitive peer ranges, e.g. @nuxt/ui's "vue": "^3.5.39" peerDependency vs. our own ^3.5.40), and nuxt typecheck still passed cleanly. Bumping our root vue dependency to ^3.5.41 added a fourth physical copy — and that's what broke it: whichever vue module the ComponentCustomProperties augmentation resolves against (via @nuxtjs/i18n's type declarations) apparently stopped being the same physical node_modules/vue copy our own .vue templates resolve vue against, so the type-level merge silently stopped applying.

Forcing a single vue resolution across the whole tree fixed it immediately, no other change:

"resolutions": {
  "vue": "3.5.40"
}

That collapsed all four buckets back into one and all ~930 errors disappeared.

What is expected?

nuxi typecheck/vue-tsc type-checking should be resilient to (or Nuxt's tooling should warn about / dedupe) multiple installed vue versions in the dependency tree, since this class of duplicate-peer-version issue seems to reliably break ComponentCustomProperties template type-checking.

What is actually happening?

Any number of coexisting vue versions apparently work fine until one specific combination causes the module-augmentation merge to target a different physical vue copy than the one templates resolve against — at which point every custom global property ($t, and any Nuxt-ecosystem auto-import used only in a template) fails type-checking with TS2339, project-wide.

Additional context

This looks closely related to nuxt/nuxt#34398 (closed as completed) and to vuejs/core#14542 (locked), both about duplicate/mismatched peer-version installs producing type-identity mismatches — there for vue-router/Component, here for vue itself via ComponentCustomProperties. Since both of those are closed/locked, filing this as its own report in case the underlying dedup issue isn't fully resolved for all trigger paths. Might be worth nuxi typecheck (or nuxt prepare) surfacing a warning when it detects more than one vue version installed, since bisecting this from the symptom alone is quite hard.