CondaSolverTimeoutError: should conda expose a configurable interrupt policy for solver timeouts?

When a conda solve operation exceeds its internal timeout, conda raises a CondaSolverTimeoutError and aborts the solve. The current implementation does not let users choose whether the abort should be immediate or whether conda should attempt to roll back any partially installed packages before exiting. This leaves temporary environment directories potentially uncleaned, especially on platforms where signal handling is inconsistent. The design decision under discussion is whether to expose a configurable interrupt policy that lets users select between an immediate abort and a graceful rollback path.

What are the implications of offering an immediate‑abort versus a graceful‑rollback option for solver timeouts?

How would a new configuration setting interact with existing automation that relies on the current error message?

Should such a policy be limited to solver timeouts or extended to user‑initiated cancellations via SIGINT?