One thing to note is that the mapping from place to time zone is also not necessarily unique, and the mapping from place to relevant political/cultural entity is also not necessarily stable.There's a common error (which is embedded in the iCalendar specification, so it's s difficult error to avoid) of recording future times as time + timezone name, instead of time + place. Of course, the mapping from place -> timezone name is not stable...
I think there's actually no right way to do this, at least not at the moment, because the whole thing is built on shifting sands and we're not able to maintain a registry of all possible adjudicating bodies for timekeeping that will ever exist.
One thing that could help with this problem and that might
be scoped well for this project to do, though, would be to ship a
machine-readable data structure that indicates something about the
history of time zone boundaries. So one example of this could be
that Asia/Qyzylorda split into Asia/Qyzylorda and Asia/Qostanay
recently. What this means is that anything that started using
Asia/Qyzylorda before the split is now ambiguous and may need to
be manually reallocated to Asia/Qostanay. Having a way to
programmatically detect when these ambiguities arise might help
things.
Maybe this already exists (outside of the changelogs) and I missed
it, though.