Backwards-compatibility for Temporal (not `DTF#resolvedOptions().timeZone`) API changes in this proposal

PR #1 proposes changing the canonicalization behavior of the following Temporal APIs: TimeZone#id, ZoneDateTime#timeZoneId, and toString/toJSON of both types. Currently, these getters and methods return the canonicalized Zone. With the changes in #1, we'd instead return the un-canonical Link identifier used to create the instances.

Assuming that Temporal will get to Stage 4 before this proposal does, will this change be blocked for backwards-compatibility reasons?

This issue is a honeypot to discuss that question. Note that backwards compatibility for Intl.DateTimeFormat.prototype.resolvedOptions() is out of scope for this issue. Please discuss that at #2.

My initial assumption is that changing Temporal is OK, for the following reasons:

For backwards compatibility concerns to apply, don't we need current compatibility? I'm asking because canonicalization is already divergent between implementations (FF canonicalizes differently than V8/WebKit), and is different across time (in FF). So callers already have to contend with unexpected variation today. It's not clear if this change will even be noticeable among the current state of variation.
The convention in ECMAScript is that localization output is allowed to vary across releases, and time zone behavior is considered to be localization output.
Temporal is a brand-new API, so even if the answers above are ambiguous, the actual real-world impact of changing Temporal behavior at this point will be limited, especially given that the changes are subtle and limited.

But if other folks disagree, let's discuss!

@sffc, you noted in a recent meeting that you thought it'd be OK to change canonicalization behavior in the future, so if you wanted to add more more info about your opinion, it'd be helpful. Thanks!

tc39 / proposal-canonical-tz

Backwards-compatibility for Temporal (not `DTF#resolvedOptions().timeZone`) API changes in this proposal #4