Global interpreter selection reads back the wrong environment #1922

Problem

In an empty VS Code window with no folder/workspace open, selecting a Python interpreter and reopening Python: Select Interpreter sometimes appears to highlight a different interpreter as the current selection. The Python Projects sidebar also appears not to update the environment shown under Global, making it difficult to confirm which interpreter is actually selected.

Observed while manually testing #1864. This report concerns selection/readback consistency, before testing terminal activation.

Repro steps (reported workflow)

1. Open an empty VS Code window with Python and Python Environments enabled and no folder/workspace open.
2. Run Python: Select Interpreter and select an environment.
3. Run Python: Select Interpreter again and inspect the apparent current selection.
4. Inspect the environment child under Global in the Python Projects sidebar.
5. Repeat with another environment; the reported mismatch is intermittent.

Expected: The current interpreter and the environment child under Global consistently reflect the last completed selection.

Actual: The picker sometimes appears to indicate a different interpreter, and the sidebar appears to retain the previous environment. The exact manager pair and whether the picker indication is keyboard focus versus an explicit current-selection marker still need confirmation. The fixed parent label Global itself is not expected to change.

Suspected cause from code inspection

Inspected revision: 30810b21fdf22e8bb38a308482391358fe8e505b. The cross-manager scenario below has not yet been independently reproduced at runtime.

• setEnvironmentsCore saves the global selection through the selected environment's manager, updates the selection cache, and emits a change event.
• setAllManagerSettings intentionally ignores edits without a project, so the global default manager is not changed.
• getConfiguredOrCachedEnvironmentManager prefers the configured/default manager over the cached selection's manager. With the default ms-python.python:venv, a selection belonging to another manager can therefore be written through one manager but subsequently read through another.
• The environment picker command and Global sidebar child both depend on this manager resolution.

This is a likely explanation for manager-dependent selection/readback mismatches, not proof of the exact reported UI symptom. A fix should preserve the intentional policy of not writing manager defaults into User settings.

Steps to verify fix

1. Open an empty window with no workspace, leave the default manager as venv, and make environments from at least two managers available.
2. Select environment A, then select B from a different manager (for example Conda or Global/system).
3. Reopen the picker and verify any explicit current-selection indication refers to B; do not use keyboard focus alone as proof of selection.
4. Expand Global in Python Projects and verify its environment child shows B; verify api.getEnvironment(undefined) also returns B.
5. Switch back to A and repeat with two environments from the same manager; verify consistent readback in both cases.
6. Cancel the picker without selecting an environment and verify the previous selection remains unchanged.
7. Clear the global selection and verify the resulting fallback is consistent between API and sidebar, without unintentionally writing global manager defaults or changing explicit folder selections.

Environment and evidence

• Workspace type: empty window, no folder/workspace.
• Exact running VS Code/extension versions and interpreter manager pair: not captured.
• Evidence: user-reported manual behavior and source inspection; no runtime reproduction, logs, or screenshots attached yet.

Related issues

• New terminals retain old interpreter after global selection changes #1864: separate shell-startup handler ignores global selection-change events, leaving new terminals on the old environment.
• Non-venv python.defaultInterpreterPath is logged as selected but the newest Python is used #1885: related configured-manager-versus-selected-manager routing problem for python.defaultInterpreterPath at startup.
• [Python Environments] Activation of any other environments fail when opening file without workspace #1522: potentially the same underlying problem when changing an interpreter for a loose file with no workspace; investigate overlap during triage.