The test validates that the new -Delimiter parameter works correctly with mixed line endings. However, there's no test coverage for the interaction between -Raw and -Delimiter parameters. When both are specified, the -Raw parameter takes precedence (ignoring -Delimiter), but this behavior should be tested to document and validate this design decision.

Consider adding a test case like:

It 'Get-Clipboard -Raw ignores -Delimiter parameter' {
    Set-Clipboard -Value "Line1`r`nLine2"
    $result = Get-Clipboard -Raw -Delimiter "`n"
    $result.Count | Should -Be 1
    $result | Should -BeExactly "Line1`r`nLine2"
}

The Delimiter parameter doesn't have validation to prevent empty or null values. If a user specifies -Delimiter @() or -Delimiter @($null), the String.Split method at line 80 would throw an exception. Consider adding [ValidateNotNullOrEmpty] attribute to the parameter to provide a clearer error message:

[Parameter]
[ArgumentCompleter(typeof(DelimiterCompleter))]
[ValidateNotNullOrEmpty]
public string[] Delimiter { get; set; } = [Environment.NewLine];

This would validate that the array itself is not null or empty, and PowerShell's built-in validation already prevents individual null elements in string arrays.

[nitpick] The DelimiterCompleter implementation uses manual WildcardPattern matching and yield return for completion results. This codebase has a CompletionHelpers.GetMatchingResults helper method (used in SeparatorArgumentCompleter in Join-String.cs) that provides consistent handling of quoting, escaping, and pattern matching for completions. Consider using it for consistency:

private static readonly IReadOnlyList<string> s_delimiterValues = new List<string>(capacity: 2)
{
    "\"`r`n\"",
    "\"`n\""
};

private static readonly Dictionary<string, (string listItemText, string toolTip)> s_delimiterDisplayInfo = new()
{
    { "\"`r`n\"", ("CRLF", "Windows (CRLF)") },
    { "\"`n\"", ("LF", "UNIX (LF)") }
};

public IEnumerable<CompletionResult> CompleteArgument(...)
{
    wordToComplete ??= string.Empty;
    return CompletionHelpers.GetMatchingResults(
        wordToComplete,
        possibleCompletionValues: s_delimiterValues,
        displayInfoMapper: value => s_delimiterDisplayInfo.TryGetValue(value, out var info) ? info : (value, value),
        resultType: CompletionResultType.ParameterValue);
}

However, the current implementation has custom logic to match against user-friendly terms like "CRLF", "Windows", "Unix", "Linux", "LF" which wouldn't work with the helper as-is. The current approach is acceptable, but the filtering logic could be simplified to be more robust.