How should a PowerShell module document whether errors terminate or continue?

Using Write-Error followed by return is not always necessary. You can emit a non-terminating error with an appropriate category and let the caller choose the action through -ErrorAction or ErrorActionPreference. That matters for pipeline commands: stopping on the first bad input and continuing past bad inputs are both useful behaviors, depending on whether the failure affects the entire operation or just one object.

For public modules, I would document the error category, whether processing continues for later pipeline inputs, and whether callers can promote the error with -ErrorAction Stop. A small behavior table in the help text or module documentation can be clearer than relying on implementation details.

There is no built-in declaration that cleanly exposes this contract. The practical approach is to document it explicitly in comment-based help, especially the NOTES section, and describe which conditions are terminating versus non-terminating. Consumers often still need to inspect the implementation or test behavior, which is a genuine weakness in PowerShell's error model.

As a general convention, commands tend to use terminating behavior when the whole operation cannot continue, and non-terminating errors when only one input object is affected. That convention helps, but it is not perfectly consistent, so documenting the module's own rules is worthwhile.

For non-terminating errors in an advanced function, prefer $PSCmdlet.WriteError() when you already have an ErrorRecord rather than relying on Write-Error. It gives you more direct control over the record and avoids some surprising interaction with automatic success-state variables.

Also make sure the function honors the common -ErrorAction behavior. A caller should be able to promote a recoverable error with -ErrorAction Stop and catch it with try/catch. Hard-coding every failure as throw can make per-input pipeline processing unnecessarily brittle.