In the scriptblock-expression branch, scriptblockBodyString is taken from scriptBlockExpr.ScriptBlock.Extent.Text, which includes the outer {}. Passing that text to ScriptBlock.Create(...) will create a script that returns a ScriptBlock object rather than executing the scriptblock body, so cases like { throw "Test Error" } &! won't fail as expected and { $using:x } &! will just output a ScriptBlock. Use the ScriptBlockAst body (or strip the outer braces and adjust offsets) so the job runs the intended statements.

This performs a regex match for every variable occurrence found in the AST, which can add noticeable overhead when backgrounding larger pipelines. Consider replacing the regex with a precomputed case-insensitive HashSet<string> (and a cheap StartsWith(\"global:\", OrdinalIgnoreCase) strip/check), or a single cached static readonly Regex if regex is preferred, to reduce per-invocation allocations and CPU.

The variable-rewrite logic (collect variables → skip checks → append spans → inject ${using:...} → create ScriptBlock) is duplicated in both branches. Consider extracting a shared helper/local function that takes (string text, int offset, IEnumerable<Ast> variables) and returns the rewritten ScriptBlock (or rewritten string). This will make future fixes (e.g., magic-variable filtering, escaping, offset math) less error-prone.

The PR description says &! should mimic the established & background operator semantics, but skipping WorkingDirectory for Start-ThreadJob will likely change the job's starting location compared to & (which does pass -WorkingDirectory). If Start-ThreadJob can't accept -WorkingDirectory, consider emulating it by prepending a Set-Location -LiteralPath <current> to the generated scriptblock (or using -InitializationScript if available), so &! preserves location semantics.

Emitting Write-Warning during test discovery/execution can add noise to CI logs even when the behavior is expected (especially since you already have -Skip gating for ThreadJob-specific assertions). Consider removing the warning or switching to Write-Verbose (so it only appears when explicitly requested).

TokenKind.AmpersandExclaim is assigned numeric value 105, but the TokenTraits tables were updated as if it were inserted immediately after Ampersand (between Ampersand and Pipe). This shifts the trait/text arrays out of alignment with the TokenKind values (e.g., TokenKind.Pipe will index into the &! entry), breaking tokenization/parsing and TokenKind.Text() results.

Fix by either (a) consuming one of the existing reserved operator slots for AmpersandExclaim and placing its flags/text at that reserved-slot index in s_staticTokenFlags/s_tokenText, or (b) renumbering subsequent TokenKind values (not recommended given the reserved-slot design).

The DEBUG assertions in TokenTraits were changed to compare table lengths against TokenKind.AmpersandExclaim + 1, but AmpersandExclaim is not the last TokenKind (keywords like Clean come later). This will cause the debug assertion to fail even when the tables are correctly sized.

The length checks should continue to use the last token in the enum (currently TokenKind.Clean).

PSToken.s_tokenKindMapping adds an AmpersandExclaim entry immediately after Ampersand, which (given TokenKind.AmpersandExclaim = 105) misaligns the mapping array indices with the TokenKind enum values and will cause incorrect PSTokenType classification for many tokens.

Once TokenKind.AmpersandExclaim is correctly slotted (likely into a reserved index), update the mapping array so the new entry is at the matching numeric index (and keep all existing indices stable).

InvokePipelineInBackground now special-cases a pipeline that is a single ScriptBlockExpressionAst and runs the script block directly. Since this method is also used for the existing background operator & (Start-Job), this change alters behavior for ... & as well, not just the new &! operator.

If the behavior change for & is intentional, please add a targeted regression test covering { ... } & semantics; if it’s meant to be &!-only, gate the special-case on pipelineAst.BackgroundThreadJob.

BeforeAll emits a warning when Start-ThreadJob isn’t available. In CI this adds noise even though the relevant tests are already conditionally skipped.

Consider removing the Write-Warning and relying on Pester’s skip reporting (or mark ThreadJob-dependent tests as skipped with a clear -Because message).

PR description/checklist indicates user-facing documentation is needed for the new &! language operator, but this PR doesn’t include any documentation updates or a linked docs issue. Please either add the doc update (or link the tracking issue/PR) so the operator is discoverable to users.

$threadJobAvailable is computed inside BeforeAll, but it’s used in the -Skip: expression on this It. The -Skip argument is evaluated when the test is defined, before BeforeAll runs, so this will likely skip (or not skip) incorrectly (e.g., $null -> skipped). Compute $threadJobAvailable at script scope / BeforeDiscovery, or move the conditional logic into the test body and call Set-ItResult -Skipped with a return.

Same issue as above: $threadJobAvailable is set in BeforeAll but used in the -Skip: argument here, which is evaluated before BeforeAll runs. This can cause the fallback test to run even when ThreadJob is available (and then fail the PSJobTypeName assertion). Move the availability detection earlier (script scope / BeforeDiscovery) or use Set-ItResult -Skipped inside the It block.

The PR description says &! runs the pipeline as a ThreadJob, but the implementation silently falls back to Start-Job when Start-ThreadJob isn’t available. That can violate user expectations for a performance-focused operator and makes behavior environment-dependent. Consider either (a) emitting a terminating error when Start-ThreadJob cannot be resolved, or (b) making the fallback explicit (warning / verbose) and documenting it (and aligning tests accordingly).