This is uncharted territory. There have been discussions around doing such a thing, but the software wasn't designed with differing performance characteristics across zones -- of course, it could certainly have its design improved to do so, at the cost of complexity.
Of the many things to consider is performance: When an object GET comes in, it is routed randomly to one of the three replicas in the system. With slower zones, one or even all of the replicas might be on the slow zones. Swift would need to be enhanced to understand fast vs. slow and try to distribute writes to be on both (with maybe the slow ones happening in the background) and distribute reads to the fast and fall back to the slow.
For a different solution, the upcoming container sync feature may fill the gap. Container sync simply sends updates from one container to another, presumably on different clusters. One might run two clusters each running with 2 replicas and then sync the two. There would be 4 total replicas, which means higher cost. The performance requirements would be met by using the cluster closest to a given client and falling back to the other cluster.
The main benefit of the container sync approach is that the Swift core is altered only slightly and the vast majority of the new complexity is contained within the sync feature itself. This keeps any new bugs outside of the standard Swift usage.
