Conda rollback and pip-installed packages: can both package managers share one atomic transaction boundary?

Conda 4.6+ wraps each install, update, and remove operation in a transaction that rolls back on failure, and conda install --revision N can revert an environment to a recorded revision. Pip, however, maintains its own installation database, and packages added with pip install inside a conda environment are not recorded in conda history.

The goal is to design an environment workflow where reverting a failed or unwanted change restores a consistent state across both managers. The uncertainty is at the integration boundary: after a conda rollback, pip-installed packages remain in place, and they may depend on conda-managed libraries that were just downgraded or removed. There appears to be no documented mechanism for extending conda's transaction log to cover pip operations, and conda env export --from-history omits pip packages entirely.

Assume a recent conda version (23.x or later, defaulting to the libmamba solver, which does not change this boundary). Behavior can be verified by creating a test environment, installing one conda package and one pip-only package such as rich, then running conda install --revision 0 and inspecting pip list and conda history.

Is there any supported way to make a rollback atomic across both conda and pip state? If not, what is the recommended pattern for tracking pip state (for example, pip freeze snapshots) so a rollback can be replayed consistently? And does mixing the two managers after a rollback risk silent dependency breakage that conda will not detect?