Ceylon module repository lacks atomic rollback after schema-breaking dependency upgrade

Context

Ceylon 1.3.3 resolves versioned modules from a flat .car repository using semantic versioning, selecting the highest compatible version per module ID. The compiler and runtime embed transitive dependency metadata in each archive, but the repository layout provides no isolation for diamond dependencies.

Problem

When a deployed module receives a schema-breaking upgrade (for example, a library moving from 1.x to 2.0.0), dependent modules that have not been recompiled against the new version fail at runtime with ClassNotFoundException or linkage errors. The standard tooling (ceylon copy, ceylon publish) performs filesystem-level replace operations without transaction boundaries, so a crash or interruption during the replace leaves the repository in a partially updated state.

Constraints

• Ceylon is archived; no language-level changes or runtime patches will be issued.
• External orchestration (Herd, custom scripts) must supply any atomicity guarantees.
• Running multiple major versions of the same module side-by-side is not supported by the resolver.

Questions

1. What external repository-layout patterns (shadow repositories, versioned subdirectories, symlink switching) have been validated to provide crash-safe rollback for a flat .car store?
2. Can ceylon resolve --verbose output be scripted to produce a deterministic manifest that a deployment pipeline can snapshot before mutation?
3. Are there documented practices for recompiling only the affected dependent modules while keeping the rest of the repository servable during the upgrade window?