Two delivery zones overlap. Which rate applies?
If you cannot answer that from the data alone, then your system is answering it from insertion order.
We ran into this while building courier and warehouse tooling for delivery marketplaces. Zones start clean: one polygon per area, no ambiguity anywhere. Then operations adds a surcharge ring around a bridge, a promo zone for a new district, a restricted area that overrides everything. Now a single address falls inside three polygons, and the lookup returns the first row the query happened to find. That result looks stable in staging, and it shifts the day someone reimports a shapefile.
The fix is small and boring: priority is a field on the zone, not a rule in the code. The point-in-zone lookup returns all matches and picks the highest priority one. The overlap is still there, it is just a decision somebody made and can review, instead of an accident.
We kept this pattern in our open-source delivery-zones project. The geometry is fairly ordinary. The part we care about is that the tie-break lives in the data, where operations people can see it, instead of buried in a query builder.
Our general take, and we think it holds pretty widely: any lookup that can return more than one row needs a declared ordering, or you have shipped a coin flip.
Somewhere in your system a silent tie-break probably decides something a customer actually pays for.