Fix incorrect case/capitalization in ref docs (#11937)

This ensures the following components have the correct/consistent case
throughout the reference documentation:

Preference variable, PS environment variable, PS drive, PS provider,
PS command name, PS command argument, PS module, PS file extension,
PS host name/application, #Requires statement, parameter name,
about_* topic, member name, scope modifier, keyword, operator,
calculated property key/value, attribute, type accelerator,
type literal/name, WMI namespace/class, variable name,
special character, comment-based help keyword, product/company name,
Windows drive letter/directory, Windows/Unix environment variable

In addition, changes include fixes to incorrect terminology (e.g.,
referring to a keyword as a command) and formatting of PS syntax
elements (non-exhaustive).

Author: surfingoldelephant

reference/7.4/Microsoft.PowerShell.Core/About/about_Thread_Jobs.md

@@ -160,7 +160,7 @@ two cases for that meet this criteria.
 
 ```powershell
 (Measure-Command {
-    1..1000 | ForEach { Start-ThreadJob { Write-Output "Hello $using:_" } } | Receive-Job -Wait
+    1..1000 | foreach { Start-ThreadJob { Write-Output "Hello $Using:_" } } | Receive-Job -Wait
 }).TotalMilliseconds
 36860.8226
 
@@ -170,13 +170,13 @@ two cases for that meet this criteria.
 7.1975
 ```
 
-The first example above shows a foreach loop that creates 1000 thread jobs to
+The first example above shows a `foreach` loop that creates 1000 thread jobs to
 do a simple string write. Due to job overhead, it takes over 36 seconds to
 complete.
 
-The second example runs the `ForEach` cmdlet to do the same 1000 operations.
-This time, `ForEach-Object` runs sequentially, on a single thread, without any
-job overhead. It completes in a mere 7 milliseconds.
+The second example runs the `ForEach-Object` cmdlet to do the same 1000
+operations. This time, `ForEach-Object` runs sequentially, on a single thread,
+without any job overhead. It completes in a mere 7 milliseconds.
 
 In the following example, up to 5000 entries are collected for 10 separate
 system logs. Since the script involves reading a number of logs, it makes sense
@@ -201,9 +201,9 @@ The script completes in half the time when the jobs are run in parallel.
 
 ```powershell
 Measure-Command {
-    $logs = $logNames | ForEach {
+    $logs = $logNames | foreach {
         Start-ThreadJob {
-            Get-WinEvent -LogName $using:_ -MaxEvents 5000 2>$null
+            Get-WinEvent -LogName $Using:_ -MaxEvents 5000 2>$null
         } -ThrottleLimit 10
     } | Wait-Job | Receive-Job
 }
@@ -218,29 +218,29 @@ $logs.Count
 There are multiple ways to pass values into the thread-based jobs.
 
 `Start-ThreadJob` can accept variables that are piped to the cmdlet, passed in
-to the script block via the `$using` keyword, or passed in via the
+to the script block via the `Using:` scope modifier, or passed in via the
 **ArgumentList** parameter.
 
 ```powershell
 $msg = "Hello"
 
 $msg | Start-ThreadJob { $input | Write-Output } | Wait-Job | Receive-Job
 
-Start-ThreadJob { Write-Output $using:msg } | Wait-Job | Receive-Job
+Start-ThreadJob { Write-Output $Using:msg } | Wait-Job | Receive-Job
 
-Start-ThreadJob { param ([string] $message) Write-Output $message } -ArgumentList @($msg) |
+Start-ThreadJob { param ([string] $Message) Write-Output $Message } -ArgumentList @($msg) |
   Wait-Job | Receive-Job
 ```
 
 `ForEach-Object -Parallel` accepts piped in variables, and variables passed
-directly to the script block via the `$using` keyword.
+directly to the script block via the `Using:` scope modifier.
 
 ```powershell
 $msg = "Hello"
 
 $msg | ForEach-Object -Parallel { Write-Output $_ } -AsJob | Wait-Job | Receive-Job
 
-1..1 | ForEach-Object -Parallel { Write-Output $using:msg } -AsJob | Wait-Job | Receive-Job
+1..1 | ForEach-Object -Parallel { Write-Output $Using:msg } -AsJob | Wait-Job | Receive-Job
 ```
 
 Since thread jobs run in the same process, any variable reference type passed
@@ -255,10 +255,10 @@ the process.
 
 ```powershell
 $threadSafeDictionary = [System.Collections.Concurrent.ConcurrentDictionary[string,object]]::new()
-$jobs = Get-Process | ForEach {
+$jobs = Get-Process | foreach {
     Start-ThreadJob {
-        $proc = $using:_
-        $dict = $using:threadSafeDictionary
+        $proc = $Using:_
+        $dict = $Using:threadSafeDictionary
         $dict.TryAdd($proc.ProcessName, $proc)
     }
 }

reference/7.4/Microsoft.PowerShell.Core/About/about_Windows_PowerShell_Compatibility.md

@@ -33,7 +33,7 @@ remoting and reflected into current PowerShell session. This is the same
 transport method used for PowerShell jobs.
 
 When a module is imported into the `WinPSCompatSession` session, implicit
-remoting generates a proxy module in the user's `$env:Temp` directory and
+remoting generates a proxy module in the user's `$Env:TEMP` directory and
 imports this proxy module into current PowerShell session. The proxy module
 allows PowerShell to detect that the module was loaded using Windows PowerShell
 Compatibility functionality.
@@ -97,7 +97,7 @@ $ConfigJSON = ConvertTo-Json -InputObject @{
   "Microsoft.PowerShell:ExecutionPolicy" = "RemoteSigned"
 }
 $ConfigJSON | Out-File -Force $ConfigPath
-pwsh -settingsFile $ConfigPath
+pwsh -SettingsFile $ConfigPath
 ```
 
 For more the latest information about module compatibility, see the
@@ -148,7 +148,7 @@ The Windows PowerShell Compatibility functionality:
 
 The Windows PowerShell Compatibility feature uses implicit remoting to make
 Windows PowerShell 5.1 modules available in PowerShell 7. Implicit remoting
-creates temporary files in the `$env:Temp` directory. Each proxied module is
+creates temporary files in the `$Env:TEMP` directory. Each proxied module is
 stored in a separate folder with the following naming convention:
 
 - `remoteIpMoProxy_<ModuleName>_<ModuleVersion>_localhost_<SessionGuid>`.
@@ -163,6 +163,6 @@ from the session or close the session.
 
 <!-- link references -->
 [01]: about_Modules.md
-[02]: about_Powershell_Config.md
+[02]: about_PowerShell_Config.md
 [03]: https://aka.ms/PSModuleCompat
 [04]: xref:Microsoft.PowerShell.Core.Import-Module

reference/7.4/Microsoft.PowerShell.Core/Disable-PSRemoting.md

@@ -248,7 +248,7 @@ disabled.
 
 ```powershell
 Disable-PSRemoting -Force
-powershell.exe -command 'Get-PSSessionConfiguration'
+powershell.exe -Command 'Get-PSSessionConfiguration'
 ```
 
 ```Output
@@ -300,8 +300,8 @@ Permission    : NT AUTHORITY\NETWORK AccessDenied, NT AUTHORITY\INTERACTIVE Acce
 ```
 
 ```powershell
-powershell.exe -command 'Disable-PSRemoting -Force'
-powershell.exe -command 'Get-PSSessionConfiguration'
+powershell.exe -Command 'Disable-PSRemoting -Force'
+powershell.exe -Command 'Get-PSSessionConfiguration'
 ```
 
 ```Output

reference/7.4/Microsoft.PowerShell.Core/Get-PSSubsystem.md

@@ -139,7 +139,7 @@ This cmdlet supports the common parameters: -Debug, -ErrorAction, -ErrorVariable
 
 ## RELATED LINKS
 
-[about_experimental_features](about/about_experimental_features.md)
+[about_Experimental_Features](about/about_experimental_features.md)
 
 [Disable-ExperimentalFeature](Disable-ExperimentalFeature.md)
 

reference/7.4/Microsoft.PowerShell.Management/Set-Clipboard.md

@@ -57,14 +57,14 @@ Set-Clipboard -Value "This is a test string" -AsOSC52
 ### Example 4: Set the default value of the **AsOSC52** parameter
 
 You can detect if you are connected to a remote session over SSH by checking the value of the
-`$env:SSH_CLIENT` or `$env:SSH_TTY` environment variables. If either of these variables are set,
+`$Env:SSH_CLIENT` or `$Env:SSH_TTY` environment variables. If either of these variables are set,
 then you are connected to a remote session over SSH. You can use this information to set the default
 value of the **AsOSC52** parameter. Add one of the following lines to your PowerShell profile
 script.
 
 ```powershell
-$PSDefaultParameterValues['Set-Clipboard:AsOSC52'] = $env:SSH_CLIENT
-$PSDefaultParameterValues['Set-Clipboard:AsOSC52'] = $env:SSH_TTY
+$PSDefaultParameterValues['Set-Clipboard:AsOSC52'] = $Env:SSH_CLIENT
+$PSDefaultParameterValues['Set-Clipboard:AsOSC52'] = $Env:SSH_TTY
 ```
 
 For more information about `$PSDefaultParameterValues`, see

reference/7.4/Microsoft.PowerShell.Management/Set-Location.md

@@ -109,7 +109,7 @@ specified in the command. For information about location stacks, see the [Notes]
 ### Example 5: Navigate location history using `+` or `-`
 
 ```
-PS C:\> Set-Location -Path $env:SystemRoot
+PS C:\> Set-Location -Path $Env:SystemRoot
 PS C:\Windows> Set-Location -Path Cert:\
 PS Cert:\> Set-Location -Path HKLM:\
 PS HKLM:\>

reference/7.4/Microsoft.PowerShell.Utility/Disable-PSBreakpoint.md

@@ -97,9 +97,9 @@ This command disables all breakpoints in the current console.
 
 ### Example 5: Disable a breakpoint in a runspace
 
-In this example, a job is started and a breakpoint is set to break when the `Set-PSBreakPoint` is
-run. The runspace is stored in a variable and passed to the `Get-PSBreakPoint` command with the
-**Runspace** parameter. The output of `Get-PSBreakPoint` is piped to `Disable-PSBreakpoint` to
+In this example, a job is started and a breakpoint is set to break when the `Set-PSBreakpoint` is
+run. The runspace is stored in a variable and passed to the `Get-PSBreakpoint` command with the
+**Runspace** parameter. The output of `Get-PSBreakpoint` is piped to `Disable-PSBreakpoint` to
 disable the breakpoint in the runspace.
 
 ```powershell
@@ -110,7 +110,7 @@ Start-Job -ScriptBlock {
 
 $runspace = Get-Runspace -Id 1
 
-Get-PSBreakPoint -Runspace $runspace | Disable-Breakpoint -Runspace $runspace
+Get-PSBreakpoint -Runspace $runspace | Disable-Breakpoint -Runspace $runspace
 ```
 
 ## PARAMETERS

reference/7.4/Microsoft.PowerShell.Utility/Enable-PSBreakpoint.md

@@ -118,8 +118,8 @@ This example is equivalent to running `Enable-PSBreakpoint -Id 3, 5`.
 ### Example 5: Enable a breakpoint in a runspace
 
 In this example, a job is started with a breakpoint is set to break then disabled. The runspace is
-stored in a variable and passed to the `Get-PSBreakPoint` command with the **Runspace** parameter.
-The output of `Get-PSBreakPoint` is piped to `Enable-PSBreakpoint` to enable the breakpoint in the
+stored in a variable and passed to the `Get-PSBreakpoint` command with the **Runspace** parameter.
+The output of `Get-PSBreakpoint` is piped to `Enable-PSBreakpoint` to enable the breakpoint in the
 runspace.
 
 ```powershell
@@ -131,7 +131,7 @@ Start-Job -ScriptBlock {
 
 $runspace = Get-Runspace -Id 1
 
-Get-PSBreakPoint -Runspace $runspace | Enable-Breakpoint -Runspace $runspace
+Get-PSBreakpoint -Runspace $runspace | Enable-Breakpoint -Runspace $runspace
 ```
 
 ## PARAMETERS

reference/7.4/Microsoft.PowerShell.Utility/Get-Error.md

@@ -47,7 +47,7 @@ In this example, `Get-Error` displays the details of the most recent error that
 current session.
 
 ```powershell
-Get-Childitem -path /NoRealDirectory
+Get-ChildItem -Path /NoRealDirectory
 Get-Error
 ```
 
@@ -86,11 +86,11 @@ InvocationInfo        :
     ScriptLineNumber : 1
     OffsetInLine     : 1
     HistoryId        : 57
-    Line             : Get-Childitem -path c:\NoRealDirectory
+    Line             : Get-ChildItem -Path C:\NoRealDirectory
     PositionMessage  : At line:1 char:1
-                       + Get-Childitem -path c:\NoRealDirectory
+                       + Get-ChildItem -Path C:\NoRealDirectory
                        + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-    InvocationName   : Get-Childitem
+    InvocationName   : Get-ChildItem
     CommandOrigin    : Internal
 ScriptStackTrace      : at <ScriptBlock>, <No file>: line 1
 PipelineIterationInfo :

reference/7.4/Microsoft.PowerShell.Utility/Join-String.md

@@ -166,7 +166,7 @@ $parms = @{
   OutputSuffix = "`n}`n"
   Separator = "`n"
 }
-$obj.PSObject.Properties | Join-String @parms
+$obj.psobject.Properties | Join-String @parms
 ```
 
 ```Output