Mirrors are for redundancy with eventual consistency. It sounds like you're asking for strong global consistency, which is a PhD level problem, and I can't really see the benefit.

Why do you want this? Why can't you just use a tier 1 mirror?

There are numerous reports/instances where mirrors are incompletely updated and folks are left with half upgraded systems. For example

1) util-linux package hasn't fully propagated to the South Korean mirrors which has caused issues since it replaces zramctl with the one from util-linux which has different cmdline options and behavior.
2) numerous bumblebee updates have failed/been delayed due to nvidia updates not propagating fully across mirrors

While I understand it's a matter of time for "eventual consistency", it seems that the pacman.d/mirrorlist file doesn't indicate what's a tier1, tier2 provider. Rankmirrors doesn't seem to take into account which tier mirrors are at either.

We update the repos atomically at tier 0 and we provide recommendations to mirrors such that they should never advertise partial upgrades as far as the mirrors are concerned. If an update to tier 0 is incomplete, then it's a dev failure. If an update to a mirror is incomplete, then it's a mirror failure. If there's package-level metadata which declares unfulfillable or incomplete dependencies, then your suggestion of providing hashes of package lists will have no effect because our repos are dumb package lists and tarballs with no introspection into the packages themselves.

As to your examples:

1) I don't know what you mean by "fully propagated". Either the package is there, or it isn't (if there's a partial package, then it's a fault of the mirror, not Arch developers). If there's a problem with package-level metadata declaring unfulfillable dependencies (or insufficient dependencies), then it's a plain ol' uninteresting bug. I suspect this is the case, and that you're hinting at some interaction between util-linux and systemd-swap, but I really don't know beyond that.

2) Could you be more specific? Failed how? Delayed how? This sounds like another case of the package metadata or some human being at fault.

1) There's no partial package, it's just that not all packages are transferred so if one syncs with a partially upgraded mirror, they will end up with a failed upgrade.
a) util-linux 2.26.1-3 didn't update globally for at least half a day leading to users with two different versions of zramctl. The issue was that the old community zramctl worked differently than the one supplied by util-linux.
2) The last two bumblebee updates have had issues with nvidia-utils not being updated in time. The upgrade fails since the proper nvidia-utils is not present. There has been also two cases from my memory in which bumblebee updated despite nvidia-utils being out of date which resulted in broken bumblebee nvidia behavior. I believe I've flagged packages out of date due to the latter and filed a bug report regarding the former.

So, the issues with repos not being atomic snapshots of tier0 is just due to unscrupulous devs?

> So, the issues with repos not being atomic snapshots of tier0 is just due to unscrupulous devs?
Calling us unscrupulous is rather dramatic and uncalled for. Mistakes happen.