but I would merge this PR only once we have a rule that needs it.

That's something of a chicken and egg problem. PSUseCompatibleSyntax could use this today, but doesn't have an ifdef to target currently. If it did, we could add visitor methods for new syntaxes that issue warnings for other versions

Ok, let me re-phrase it then: Do we want to get 1.19.0 out of the door in 1-2 weeks or 1-2 months? Because taking advantage of those new APIs will take some time or do you guys plan to spend much more time on PSSA for those PRs since PS and the extension have shipped now? I'm up for either approach (fast releases or wait longer for just 1 release), just want to be sure we are all on the same page.

Ok, let me re-phrase it then: Do we want to get 1.19.0 out of the door in 1-2 weeks or 1-2 months? Because taking advantage of those new APIs will take some time or do you guys plan to spend much more time on PSSA for those PRs since PS and the extension have shipped now? I'm up for either approach (fast releases or wait longer for just 1 release), just want to be sure we are all on the same page.

Could you expand on this some more? Which PRs are you referring to? Which changes do you mean will take advantage of the new APIs?

As far as I can think, the only rule that would easily take advantage of the new AST elements is the compatible syntax rule. Currently most of the rules just pick up the ASTs they're normally looking for, and they'll continue to do that when targeting PS7 APIs. Are there other rules you have in mind for changes?

OK, that sounds good if it is just your compatibility syntax rule, I thought the scope could've been bigger. Totally OK if you want to have this change as part of 1.19.0
In a few days, Azure Pipelines images are likely going to update PowerShell to 7.0 so testing is going to be interesting for 6.2 in the next months until it goes out of support in 6 months...
Will have a re-review around some of the build related changes. So far the only problem that I could spot is the issue that we also need conditions for the version of Microsoft.Management.Infrastructure.

@JamesWTruher @bergmeister this should be ready to go now, if you're able to sign off or let me know what else should be changed

Just a question for my own understanding/education: Jim said that one should use the Microsoft.PowerShell.SDK NuGet package and not the SMA one, why?

Ok I've now had a discussion with members of the PowerShell team on this one, and I think for our purposes, SMA is the right target for now. I'm hoping to write documentation of some kind to address this in the next week or so

Ok I've now had a discussion with members of the PowerShell team on this one, and I think for our purposes, SMA is the right target for now. I'm hoping to write documentation of some kind to address this in the next week or so

Interesting, thanks.
My simplistic understanding as a user is that SMA is to be used for when .net code is executed from within PowerShell itself as a reference assembly of SMA APIs since PowerShell itself already has all required assemblies. I'd use the SDK if the code was running as part of a 'normal' .net app that doesn't have the PowerShell dependencies like the SMA Dll and its other dependent assemblies so that a dotnet publish contains those DLLs and therefore ships a self-contained version of the PowerShell 'runtime' (also meaning that the author would be in charge of patching)

Basically the outcome of our discussion was:

• Use SMA for just parsing, minimal hosting using SessionState.CreateDefault2() and only commands in the Microsoft.PowerShell.Core module, or when you need a reference assembly with version-specific APIs
• Use the SDK for hosted scenarios where arbitrary commands or modules may be used or where code references are required to other Microsoft.PowerShell.* module types
• Use PSStd for all reference (rather than hosted) scenarios where version-specific APIs are not required

Basically PSStd is a facade with no implementation, but it's a common denominator facade so omits version-specific APIs.

SMA is just the engine DLL, so doesn't come with the whole of what ships today as "PowerShell". It's enough to parse and run very basic PowerShell scripts, but doesn't have the modules or other required bits like the refs folder needed for Add-Type.

The SDK is the whole circus, with everything needed to run PowerShell just like pwsh.exe. But if you're just trying to compile against PowerShell as a module, it's probably overkill.