Reproduced the mechanism in packages/vite/src/node/utils.ts — the mutation is structural, not incidental:

export function setupHmrWsOptionCompat(
  serverConfig: Pick<ServerOptions, 'hmr' | 'ws'>,
): void {
  ...
  const hmrConfig = serverConfig.hmr          // ← reference, never copied
  ...
  const hmrProxy = hmrConfig || {}
  for (const key of wsOptionKeys) {
    Object.defineProperty(hmrProxy, key, {    // ← accessors land on the caller's object
      get() {
        return (serverConfig.ws as Record<string, unknown>)?.[key]
      },
      ...
    })
  }
}

and it's reached from the merge path:

if (rootPath === 'server') {
  setupHmrWsOptionCompat(merged)
}

hmrConfig is taken by reference and Object.defineProperty is called straight onto it, so whatever object serverConfig.hmr points at gets accessor properties installed permanently. Nothing clones it first.

That explains both symptoms in your repro. Once the first mergeConfig has run, defaults.server.hmr carries live accessors delegating to that first call's serverConfig.ws. So Object.hasOwn(defaults.server.hmr, 'port') is true, and the second merge — which is otherwise completely independent — resolves hmr.host/hmr.port through the leftover accessors into the first merge's ws object, inheriting port: 3000.

A couple of details worth noting for whoever picks this up:

The nearby rootPath === 'server.hmr' branch (L1480-1486) explicitly copies property descriptors from defaults onto merged, so the accessors are meant to survive a merge — they just aren't meant to be written back into the caller's input object. That suggests the fix is to define them on a copy, e.g. const hmrProxy = { ...hmrConfig }, rather than to stop installing them. Though that needs care: the hmr === true case just above assigns serverConfig.hmr = {} on the caller's object too, so there may be more than one place serverConfig itself is written to.
wsOptionKeys is iterated with a plain for...of and no guard, so if a key already has a non-configurable descriptor the defineProperty would throw. Cloning first would incidentally avoid that, which may be worth a test.

I haven't run this against a local build — I read the source rather than executing your repro, so I'd want to confirm the second.server.ws shape you pasted on the current main before treating my read as complete.

If it's useful I can put up a PR, though I'd rather someone confirm the intended semantics first: should mergeConfig guarantee it never writes to either input, or is it acceptable for the compat accessors to be attached to a shallow copy that the caller then owns?

Sunbelt Computer Software

PL/B Language Development and Support