Stacked PR. Base branch = dev/janprovaznik/server-gc (the Server GC PR). This PR shows only the delta on top of it. Review/merge the base first. This supersedes dotnet#13758 (same intent, rebased onto the Server GC work and refactored to share its -mt detection).

-mt implies MSBuild Server (with MSBUILDUSESERVER=0 opt-out)

When -mt is on the command line and MSBUILDUSESERVER is unset, automatically engage MSBuild Server. Explicit MSBUILDUSESERVER=0 always opts out (takes precedence over the implicit -mt opt-in).

Why stack on the Server GC PR?

The base PR introduced a single, canonical answer to one question — "is this a -mt build?" — and used it to decide whether the server gets Server GC. This PR needs the same answer to decide whether to engage the server at all. Stacking lets both decisions share one -mt detector instead of each shipping its own (the standalone dotnet#13758 carried a private CommandLineContainsMultiThreadedSwitch, duplicating exactly what the base PR already had to reason about).

Combined decision flow

                          MSBuild.exe Main(args)
                                   │
                 ┌─────────────────▼─────────────────┐
                 │  multiThreaded = IsMultiThreaded   │   ← ONE lightweight scan
                 │     Requested(args)                │     (-mt / -multithreaded,
                 │  (cmdline -mt  ||  FORCE env var)  │      or MSBUILDFORCEMULTITHREADED)
                 └─────────────────┬─────────────────┘
                                   │ multiThreaded
              ┌────────────────────┴───────────────────────┐
              ▼                                             ▼
   ┌─────────────────────┐                  (passed through to the server launch)
   │ ShouldUseMSBuild     │                              │
   │ Server(multiThreaded)│  THIS PR                     │
   ├─────────────────────-┤                              │
   │ USESERVER=1 → yes     (EnvVar)                       │
   │ USESERVER=0 → no      (opt-out wins)                 │
   │ unset & mt  → yes     (ImpliedByMt)                  │
   │ unset & !mt → no                                     │
   └──────────┬──────────-┘                              │
              │ use server?                              │
              ▼                                          ▼
   ┌──────────────────────┐            ┌──────────────────────────────────────┐
   │ CanRunServerBasedOn   │            │ MSBuildClientApp.Execute(             │
   │ CommandLineSwitches   │  yes  ───▶ │   args, multiThreaded, ct)            │
   │ (help/version/binlog/ │            │     │                                │
   │  nodereuse gate)      │            │     ▼  TryLaunchServer                │
   └──────────────────────┘            │  if (multiThreaded &&                 │  BASE PR
                                        │      DOTNET_gcServer unset)           │
                                        │    server launched w/ Server GC       │
                                        └──────────────────────────────────────┘

The single multiThreaded value drives two decisions: (1) whether to engage the server (this PR), and (2) how the server is launched — Server GC (base PR). They stay distinct (a MSBUILDUSESERVER=1, non--mt build engages the server without Server GC), but share one input.

Decision table

Does stacking enable further refactors for the decision + telemetry? — Yes

1. One -mt detector. IsMultiThreadedRequested(args) is now the sole source; the base PR's CanRunServerBasedOnCommandLineSwitches(out multiThreaded) out-parameter is reverted to the original signature, and [Server] -mt implies MSBuild Server dotnet/msbuild#13758's private duplicate is gone.
2. Centralized engagement decision. ShouldUseMSBuildServer(multiThreaded, out reason) is now the place server routing is decided in Main, replacing the inline EnvVar == "1" check. Future inputs (e.g. a config-file default, a new switch) plug in here.
3. Telemetry alongside the decision. ServerEnableReason (EnvVar / ImpliedByMt) is emitted right where the decision is made, so the existing ServerFallbackReason and this new field form a coherent server-routing telemetry surface.

Implementation

• XMake.Main: compute multiThreaded once; gate on ShouldUseMSBuildServer(multiThreaded, out reason); set ServerEnableReason; revert CanRunServerBasedOnCommandLineSwitches to its 1-arg form.
• IsMultiThreadedRequested(args): lightweight scan (no full GatherAllSwitches on the hot no-server path), honors -mt:false/:0 and MSBUILDFORCEMULTITHREADED. Conservative on parse problems (declines the implicit opt-in only; =1 unaffected).
• BuildTelemetry.ServerEnableReason.
• Spec: documentation/specs/multithreading/multithreaded-msbuild.md.

Test

MSBuildServer_Tests.ServerStartsWhenMtPresentEvenWithoutEnvVar — two consecutive -mt builds with MSBUILDUSESERVER unset reuse the same server PID (server reuse is the unique signature). All 14 MSBuildServer_Tests pass, including the base PR's Server-GC tests.

Open questions

1. Telemetry value name "ImpliedByMt" — or something more neutral ("MtSwitch")?
2. Should the opt-out also accept MSBUILDUSESERVER=false/no for symmetry with other Boolean MSBuild env vars?
3. -mt from a response file is not detected by the lightweight scan (so it triggers neither implicit server nor Server GC). Consistent across both decisions, but worth confirming we don't want the (more expensive) full-parse detection here.
4. MSBUILDFORCEMULTITHREADED=1 now implies server too (resolves [Server] -mt implies MSBuild Server dotnet/msbuild#13758's open Q3 affirmatively, for consistency with the Server GC determination) — confirm desired.