PR Summary

This pull request introduces support for the PowerShell "PSContentPath" experimental feature, allowing users to customize the location of user content (such as modules and scripts) via an environment variable or configuration file. The code now prefers these new paths when the feature is enabled, improving flexibility and future compatibility.

Support for PSContentPath experimental feature:

• Added logic to detect if the "PSContentPath" experimental feature is enabled by checking the PowerShell configuration file (powershell.config.json).
• When enabled, the code looks for a customPSUserContentPath in the environment variable or configuration file, using it as the base path for user content if it exists. If not set, it defaults toLocalApplicationData\PowerShell.
• If the experimental feature is not enabled, the code continues to use the legacyMyDocuments\PowerShell folder for user content.

Refactoring and path resolution:

• UpdatedGetPathsFromEnvVarAndScope to use the newpsUserContentPath variable instead of the legacy documents path, ensuring the correct directory is used based on feature detection.

Utility methods:

• Introduced two new helper methods:IsExperimentalFeatureEnabled (to check for enabled features in the config) andGetPSUserContentPath (to retrieve the custom user content path from environment or config).

PR Context

This change introduces support for the PowerShell PSContentPath experimental feature, enabling users to customize where PowerShell stores user content (modules, scripts, etc.). Historically, PowerShell has relied on fixed paths such as MyDocuments\PowerShell, which limits flexibility in modern environments. With this update, users can define a custom content path via an environment variable or configuration file, allowing PowerShell to adapt to diverse deployment and security scenarios.

The feature is a direct response to long-standing community feedback (seePowerShell/PowerShell#15552) and aligns with related work in#1912. It was shaped through detailed specifications inPowerShell/PowerShell-RFC#388. This milestone lays the foundation for flexible, user-configurable content storage, addressing needs such as:

Roaming profiles
Containerized environments
Read-only file systems

By introducing this capability, we empower users to tailor PowerShell to modern deployment and compliance requirements.

PR Checklist

• PR has a meaningful title
  • Use the present tense and imperative mood when describing your changes
• Summarized changes
• Make sure all.h,.cpp,.cs,.ps1 and.psm1 files have the correct copyright header
• This PR is ready to merge and is notWork in Progress.
  • If the PR is work in progress, please add the prefixWIP: or[ WIP ] to the beginning of the title (theWIP bot will keep its status check atPending while the prefix is present) and remove the prefix when the PR is ready.
• Breaking changes
  • None
  • OR
  • Documentation needed
    • Issue filed:
• User-facing changes
  • Not Applicable
  • OR
  • Documentation needed
    • Issue filed:
• Testing - New and feature
  • N/A or can only be tested interactively
  • OR
  • Make sure you've added a new test if existing tests do not effectively test the code changed
• Tooling
  • I have considered the user experience from a tooling perspective and don't believe tooling will be impacted.
  • OR
  • I have considered the user experience from a tooling perspective and enumerated concerns in the summary.