Removing time zone canonicalization in `Intl.DateTimeFormat` will change behavior of Temporal polyfills

Currently, polyfills rely on time zone canonicalization of Intl.DateTimeFormat to implement Temporal's time zone canonicalization used in TimeZoneEquals.

the reference polyfill:

https://github.com/tc39/proposal-temporal/blob/171f1c3b630f91b1a0bba80ce5cbfcfa5b14c478/polyfill/lib/ecmascript.mjs#L2221

@js-temporal/polyfill:

https://github.com/js-temporal/temporal-polyfill/blob/83a63b1cf082202375bc5bae800cc95bb179d8ab/lib/ecmascript.ts#L2572

temporal-polyfill:

https://github.com/fullcalendar/temporal-polyfill/blob/03c0f8e2075266b06d7e578a47a2e41fb472d8c7/packages/temporal-polyfill/src/internal/compare.ts#L222 and https://github.com/fullcalendar/temporal-polyfill/blob/03c0f8e2075266b06d7e578a47a2e41fb472d8c7/packages/temporal-polyfill/src/internal/timeZoneId.ts#L28

temporal-polyfill-lite:

https://github.com/fabon-f/temporal-polyfill-lite/blob/30b6ddf0f405207c757f8495a3230667b3d0b43b/src/internal/timeZones.ts#L396-L397

However, Temporal proposal is removing canonicalization in Intl.DateTimeFormat (original PR is https://github.com/tc39/proposal-canonical-tz/pull/15), so behavior of polyfills will change when time zone canonicalization proposal will be shipped, especially in projects using a Temporal polyfill as a ponyfill or in the way which overwrites the native implemetation (e.g. importing temporal-polyfill/global overwrites globalThis.Temporal even if the native implementation exists).

First question is "will this change break the web?". It is definitely a normative change, but I suspect that virtually no project will be affected:

1. I think comparing ZonedDateTime of two linked time zones is a rare use case.
2. Time zone canonicalization in polyfills doesn't work as expected across browsers in the first place, because JSC doesn't canonicalize time zones in Intl.DateTimeFormat (I didn't dig into this discrepancy but maybe because JSC ships time zone canonicalization proposal before Temporal?).
3. I guess no library other than Temporal polyfills rely on canonicalization behavior

new Temporal.ZonedDateTime(0n, "Europe/Kiev").equals(new Temporal.ZonedDateTime(0n, "Europe/Kyiv"));
// `true` in V8 and SpiderMonkey (native implementation and polyfill)
// `false` in latest JSC (polyfill)

If this normative change is safe, second question is "How should polyfills deal with this upcoming change?".

A significant numbers of developers seem to want to use a Temporal polyfill as a ponyfill, so they may use polyfills even in the future version of browsers after time zone canonicalization proposal will be shipped.

The only solution I came up with is delegating TimeZoneEquals to the native Temporal implementation if it exists. It sounds very weird that a Temporal polyfill relies on native Temporal implementation though.

Start with TimeZoneEquals and the canonicalization paths in polyfill/lib/ecmascript.mjs, lib/ecmascript.ts, compare.ts, timeZoneId.ts, and timeZones.ts. Reproduce the Europe/Kiev versus Europe/Kyiv comparison across the cited engines and review the Intl.DateTimeFormat change. Done means documenting whether the normative change is safe and deciding how polyfills should handle it.