Which repository priority rules govern zypper’s dependency resolution in mixed Leap/Tumbleweed environments?

Goal

To determine the exact rules zypper follows when selecting package versions during a dependency conflict in a mixed Leap/Tumbleweed setup, and to assess whether a failed transaction triggers a complete rollback of all file system changes, including configuration files.

Constraints

• Mixed Leap and Tumbleweed repositories with differing priorities.
• Potential stale metadata cached by zypper.
• Custom repository pinning may override default priorities.

Unresolved Behavior

Current documentation states that zypper favors higher‑priority repositories, but it is unclear if this rule applies uniformly across all dependency types and whether the rollback process restores every modified file or leaves residual changes.

Questions

1. Which exact priority algorithm does zypper use when resolving dependencies that span multiple repositories, and does the algorithm change between Leap and Tumbleweed releases?
2. When a transaction fails, does zypper guarantee a full rollback of all file system modifications, including altered or newly created configuration files, or can some changes persist after the rollback?