If user intention is to migrate content to new location I believe the new cmdlets should help them.
I'd like to get not only current content path but size tooGet-PSContentPath -MeasureSize.

@jshigetomi - Please mark this PR as a Draft & go through the PR checklist & mark things appropriately add some PR Context as isrequested in the PR template.

Until all thats done we shouldn't look to accept this pr.

You can do better than this & should do so in future too.
@iSazonov re this
I'd like to get not only current content path but size too Get-PSContentPath -MeasureSize.
I don't disagree on having that ability too.

@kilasuit - Thanks for calling me out on that. Definitely intended this as a draft.

@iSazonov Get-PSContentPath is only available when the PSContentPath experimental feature is enabled. When enabled, the content path defaults to LocalAppData rather than the OneDrive-synced Documents folder. This means -MeasureSize would only be useful if a user explicitly sets their content path back to the OneDrive location, which defeats the purpose of the feature.

Should we consider making Get-PSContentPath available outside the experimental feature gate? That way users could measure their current Documents\PowerShell directory size even without enabling the feature.

Should we consider making Get-PSContentPath available outside the experimental feature gate? That way users could measure their current Documents\PowerShell directory size even without enabling the feature.

I think that makes sense, perhaps this can also be provided via a script published to the gallery?

@iSazonov Get-PSContentPath is only available when the PSContentPath experimental feature is enabled. When enabled, the content path defaults to LocalAppData rather than the OneDrive-synced Documents folder. This means -MeasureSize would only be useful if a user explicitly sets their content path back to the OneDrive location, which defeats the purpose of the feature.

Should we consider making Get-PSContentPath available outside the experimental feature gate? That way users could measure their current Documents\PowerShell directory size even without enabling the feature.

I would make this question more generalized. What will migration look like? And do we want to automate it somehow?

Can you describe the migration process? How will users be forced to act after installing a new version with support for this feature?

@iSazonov@kilasuit
Great feedback! The migration process is worth discussing with the community.
I think there was a decision to not automate migration and leave that up to users.
However, we can provide a script/instructions on migration.

Current Migration Steps:

1. Find your OneDrive content path: ($env:PSModulePath -split ';')[0] | Split-Path -Parent
2. Enable the feature: Enable-ExperimentalFeature -Name PSContentPath
3. Restart PowerShell
4. (Optional) Set custom path: Set-PSContentPath -Path "Desired\Path"
5. Copy content: Copy-Item -Path $oldPath -Destination (Get-PSContentPath) -Recurse

Question: Should Get-PSContentPath support a -Legacy parameter to return the old Documents/OneDrive path? This would eliminate the need for PSModulePath parsing.

If we try to automate migration, it will most likely be a breaking change, because we cannot know all the real scenarios.
Historically, MSFT's policy is to avoid such situations. It is great policy.
Automation also eliminates the possibility of having this innovation as an experimental feature, since disabling it will not revert the migration operations performed.

To avoid these problems, I see one way - to put the new paths in the first place and keep the old ones in the second.
Then installing a new OS system or updating pwsh on existing OS systems won't break anything. At least there is a low risk, which is always present when updating versions.
New modules (resources) will be installed using new paths. If this breaks something, users can either migrate their environment or just disable the new feature without extra steps (coping files back).

Gradually, all the resources will end up in new folders.

Then, at the second stage (v7.7?), we will be able to disable the old paths by default, but users will be able to turn them back on explicitly.
At the third stage (v7.8?), the old paths can be excluded from the code altogether.

Question: Should Get-PSContentPath support a -Legacy parameter to return the old Documents/OneDrive path?

I think this makes sense too.

Then, at the second stage (v7.7?), we will be able to disable the old paths by default, but users will be able to turn them back on explicitly.
At the third stage (v7.8?), the old paths can be excluded from the code altogether.

I think the plan would be that this is all contained within 7.6.x as not to drag this out for more years but that's something that@jshigetomi & team can confirm on, but that was my expectation at least

It's probably too late, but I wondered if setting the content path for a given PWSH session could not be set in JSON such as powershell,config.json It would decrease the need for cmdlets. A community module could add functions to get-/set) if really needed.

@doctordns if added topowershell.config.json it would not negate or decrease the need for a cmdlet here as tbh most don't seem AFAIK to make use of that file, though happy to be wrong on that.
Also no this cannot be a community module, it needs to be a Microsoft one and if needed can be shipped seperately to the gallery and pulled in to the release via thisPSGalleryModules.csproj file