So the problem is two-fold, right?
a) you need to see the timestamp in different timezone(s)
A minor mode with home-zone/visiting-zone vars showing dual times via overlays answers: e.g. "It's 1PM here, what's that in London?" That's the world-clock problem. Useful, easy to solve in ~15 min.
b) anchor an event to a foreign zone permanently - you want to record a fact about an event that is intrinsically tied to a zone
For that, yes, you'd have to either change a bunch of things about Org-mode - every consumer of timestamps (agenda, clock, deadlines, repeaters) would need to become zone-aware.
Pragmatically, you can store the zone without rewriting Org, by piggybacking on a property/tag and a conversion step.
1. Author in foreign zone, but store normalized to one canonical zone (e.g. UTC) in the timestamp, and keep the original zone in a property:
* Meeting
:PROPERTIES:
:TZ: Europe/London
:END:
; UTC
2. A small minor mode renders the display via overlay in either the stored :TZ: or your current zone, computed with `format-time-string … zone`.
The limitation is that all the timestamps within a single heading can only be of a single timezone.
---
There's yet another alternative - you can codify the TZ on each timestamp as a propertized text. The problem? Text properties don't get persisted, so you'd have to add custom logic that mangles the timestamps in the file on save (essentially breaking them for all dowstream consumers), and then restores them to normal shape with propertized timezone info. I guess this begets another problem - many Org operations reconstruct the timestamp string from a parsed org-element struct.
I guess, I do stand corrected - if the problem you want to solve is "b" - there isn't a straightforward solution to it.