👍 re centralizing tab-completion customizations in principle, but surfacing them (publicly) in PowerShell itself strikes me as the wrong place; instead, they should be surfaced via PSReadLine or via PSES - see also: #18942 (comment)

Add a new variable similar to $PSStyle that contains all tabexpansion options, it could be called $PSTabExpansionOptions. Another option would be to add 2 commands: Get-TabExpansionOption and Set-TabExpansionOption.

Is it conceivable we would ever get tab-completion for a subset of native commands? I find it slightly odd that Powershell cannot tab-complete for pwsh. Other candidates would be commands that cmdlets call down to, like the DISM cmdlets. If I use dism.exe, Powershell won't help by tab-completion, even though it knows (in a sense) how to. Hypothetically:
Set-TabExpansionOption -KnownExecutables $true

@Andrew74L, providing tab-completion for an open-ended set of external CLIs is obviously impossible for PowerShell to provide itself (though you could argue that for pwsh itself it should indeed be built in).

Third-party, community-supported projects are the solution - see the posh-cli module (repository is here).

Third-party, community-supported projects are the solution - see the posh-cli module (repository is here).

Thanks Michael

@mklement0 The problem with that approach is that every time a new option is added every interactive host author needs to update their app separately, and for editors that are no longer maintained (like ISE) you just lose the ability to set new options.
In the case of PSReadline it could also cause some confusion if people are running an older version of PowerShell with a new version of PSReadline and see a new feature that is unavailable to them.

PSReadLine is (a) the module that provides the interactive command-line editing experience, and (b) is bundled with PowerShell.

Yes, the fact that you can update PSReadLine independently of PowerShell is problematic (a problem that already affects Windows PowerShell with Set-PSReadLineOption -PredictionSource, for instance).

But I think that would be outweighed by the confusion that controlling the interactive experience in two distinct places, with different syntax would invite.