Default Cache Reuse vs Forced Refresh: Addressing Stale Image Results in Podman

In current Podman releases, the default pull behavior reuses locally stored image layers and manifests, only downloading new data when the registry manifest digest changes. When a registry image is retagged without altering its digest, the local cache may serve stale content that does not reflect the intended registry state. This creates a design tension: relying on the cache reduces network overhead but risks serving outdated images, while forcing a complete re‑download via --pull=always or --policy=always guarantees freshness at the cost of consistent bandwidth usage and potential rate‑limit triggers. No built‑in TTL‑based eviction policy exists to automate cache invalidation, and manual pruning carries the risk of removing layers still referenced by running containers.

How should administrators balance cache efficiency against guaranteed freshness in environments with frequent retagging? What policy mechanisms could mitigate stale cache results without incurring unnecessary traffic? Is there a viable middle ground between default cache reuse and always‑pull strategies that respects both storage constraints and image currency?