Settings UI shows undefined for default values in nested configuration keys

[n-gist]

In my extension I group settings like:

• focus.behavior.folders
• focus.behavior.folders.external
• focus.behavior.folders.explore

Where:

• folders → default folder behavior
• folders.external → behavior for external folders
• folders.explore → behavior for explored folders

This works correctly in settings.json IntelliSense, but in Settings UI and runtime extended entries reads as undefined instead of the configured default value.

Reproduction

  "contributes": {
    "configuration": [
      {
        "title": "Repro",
        "properties": {
          "repro.test": {
            "type": "string",
            "enum": ["a", "b"],
            "default": "b",
            "description": "Works correctly"
          },
          "repro.test.extra": {
            "type": "string",
            "enum": ["a", "b"],
            "default": "b",
            "description": "Works in settings.json IntelliSense but shows undefined in UI"
          }
        }
      }
    ]  
  }

Works in settings.json:

Issue in Settings UI:

Repo:

git clone https://github.com/n-gist/vscode.settings-ui-undefined-repro.git

Expected

Settings UI should display the correct default value.

[n-gist]

Runtime behavior. Values corresponding to repro.test, repro.test.extra:

1. If nothing is overridden: b (correct), undefined (incorrect)
2. If repro.test.extra is overridden: object (incorrect), value (correct)
3. If repro.test is overridden: value (correct), undefined (incorrect) and no reaction on overriding repro.test.extra

These inconsistencies are unexpected, even if the behavior is intended.

[n-gist]

This introduces a constraint: once a setting key is defined, no other keys may exist with the same prefix followed by .

In case this behavior is intentional or due to performance constraints, I’d like to illustrate how it can significantly increase the complexity of settings key naming, in case the behavior could be revised.

Workaround A

Instead of:

focus.behavior.folders
focus.behavior.folders.external
focus.behavior.folders.explore

Use:

focus.behavior.folders.default
focus.behavior.folders.external
focus.behavior.folders.explore

If later an additional configurable behavior is introduced, such as doubleClick, it would be natural to extend it like this:

focus.behavior.folders.default
focus.behavior.folders.default.doubleClick
focus.behavior.folders.external
focus.behavior.folders.external.doubleClick
focus.behavior.folders.explore
focus.behavior.folders.explore.doubleClick

However, this approach does not work correctly. It requires restructuring to:

focus.behavior.folders.default.singleClick
focus.behavior.folders.default.doubleClick
focus.behavior.folders.external.singleClick
focus.behavior.folders.external.doubleClick
focus.behavior.folders.explore.singleClick
focus.behavior.folders.explore.doubleClick

While this works, it introduces a breaking change for existing extension users.

Workaround B

Instead of:

focus.behavior.folders
focus.behavior.folders.external
focus.behavior.folders.explore

Use:

focus.behavior.folders
focus.behavior.foldersExternal
focus.behavior.foldersExplore

Later extending with:

focus.behavior.folders
focus.behavior.foldersDoubleClick
focus.behavior.foldersExternal
focus.behavior.foldersExternalDoubleClick
focus.behavior.foldersExplore
focus.behavior.foldersExploreDoubleClick

This approach avoids breaking changes, but results in worse grouping and increasingly long, less structured keys.