No Abort in PostCSS 8: Who Owns the Timeout for a Hung Async Plugin?

On PostCSS 8, a plugin may return a Promise from its root handler or visitor hooks, and process() returns a LazyResult that settles only when every plugin finishes. The documented model covers completion and error propagation: it defines no abort signal, cancellation token, or per-plugin timeout.

That leaves an open design question for anyone embedding PostCSS under a latency budget. A plugin awaiting an external resource can hold the pipeline open indefinitely. A caller can race the LazyResult against an external deadline, but rejecting that race only abandons the caller's await; the plugin's pending work continues, and nothing in the API says what it may still touch. Deferred execution complicates this further: plugin work starts when .css, .root, .then(), or .catch() is first accessed, so a deadline measured from the process() call differs from one measured at actual start.

The unresolved decision is where responsibility for bounding plugin time belongs:

• Is run-to-completion the intended contract once process() is invoked, or is any sanctioned interruption path planned?
• When a caller times out and abandons a LazyResult, what is the expected state of the plugin's pending promises and the eventual Result?
• Should per-plugin deadlines be a core feature, an integrator concern, or a convention left to plugin authors?