Consider the following "inner" extension function, following the guidance of the README:

The Test-SecretVault cmdlet should write all errors that occur during the test. But only a single true/false boolean should be written the the output pipeline indicating success.

function Test-SecretVault {
    [CmdletBinding()]
    param(
        [Parameter(ValueFromPipelineByPropertyName,Mandatory)]
        [string]$VaultName,
        [Parameter(ValueFromPipelineByPropertyName)]
        [hashtable]$AdditionalParameters = (get-secretvault $VaultName).VaultParameters
    )

    Write-Error "Error 1"
    Write-Error "Error 2"
    Write-Error "Error 3"
    return $false
}

If you invoke the "outer" Test-SecretVault -ErrorVariable myerrors, the $myerrors will be blank, giving the user no recourse to investigate errors other than extremely error-prone parsing of $error

If you invoke Test-SecretVault -ErrorAction stop, the first inner error becomes a terminating error and causes the outer module to throw an exception with that error as the inner exception, completely ignoring the reporting of the other test errors.

If you adjust the inner function with a trap or force erroraction preference such that write-error occurs regardless, then the user cannot use try/catch to deal with these errors because they stay strictly non-terminating even with erroractionpreference='stop' or -Erroraction stop

We need a consistent and reliable way to report errors to the user in such ways that they can handle exceptions or errors that occur in secrets, either via providing the nonterminating errors via the errorvariable, or some other means that doesn't drastically alter behavior depending on the user's erroractionpreference setting.

Workaround

Use Write-Warning for nonterminating errors and throw for abnormal behavior. This resolves issues around erroractionpreference.