There are distinct "scope domains", called "(internal) session states" in the source code, that make up a single PowerShell session, as explained in this excellent blog post by @SeeminglyScience.

Documenting these in about_Scopes and giving them a descriptive official name is important.

The summary is:

• All non-module code runs in a hierarchy of scopes whose root scope is the one and only global scope.

• All module code runs in a module-specific hierarchy of scopes that has its own root scope.

  • However, the global scope's definitions are still visible in module code.

In other words: the only shared ancestral scope whose definitions are visible to both module and non-module code is the global scope.

I propose not calling these distinct scope hierarchies session states, because the latter suggests a concept relating to a session as a whole, which is confusing. Additionally, global session state is confusing, because only its root scope is truly global. Finally, it is confusing that the word scope is not in the name at all.

(As far as I know, the concepts aren't currently explained anywhere, but the confusing terms are used in https://docs.microsoft.com/en-us/powershell/developer/module/how-to-write-a-powershell-module-manifest)

I propose the term scope domain for these distinct scope hierarchies, but that is open to debate:

• The global "session state" would be called default scope domain.
• Module-specific "session states" would be called module scope domains.

@SeeminglyScience has voiced concerns in PowerShell/PowerShell#8988 (comment):

The word domain makes me think of something as Runspace level.

Perhaps scope stack is a better alternative (though, strictly speaking, it can be a tree in that multiple sibling child scopes can exist in a single pipeline).

Version(s) of document impacted

• Impacts 6.next document
• Impacts 6 document
• Impacts 5.1 document
• Impacts 5.0 document
• Impacts 4.0 document
• Impacts 3.0 document