Canonicalization between ApplyOptionsToTag and ApplyUnicodeExtensionToTag with grandfathered tags

[anba]

Consider this example:

var loc = new Intl.Locale("en-gb-oed", {region: "US", calendar: "gregory"});
print(loc.toString()); "en-GB-oxendict-u-ca-gregory"

If a grandfathered tag has a modern replacement, calling CanonicalizeLanguageTag will change the grandfathered tag into a normal langtag language tag. And that means options applied in ApplyOptionsToTag are ignored, but options applied in ApplyUnicodeExtensionToTag are used. Do we want to support this behaviour or do we rather want to ignore all options if the original input was a grandfathered language tag?

[Ms2ger]

The strange thing is that passing the Locale object through the constructor again with the same options yields a different result:

var options = {region: "US", calendar: "gregory"}
var loc = new Intl.Locale("en-gb-oed", options);
var loc2 = new Intl.Locale(loc, options);
assert.sameValue(loc.toString(), loc2.toString())
// Expected SameValue(«en-GB-oxendict-u-ca-gregory», «en-US-oxendict-u-ca-gregory») to be true

Should we perhaps canonicalize the grandfathered tags first?

[littledan]

@anba

And that means options applied in ApplyOptionsToTag are ignored, but options applied in ApplyUnicodeExtensionToTag are used.

Oops, good catch.

@Ms2ger

Should we perhaps canonicalize the grandfathered tags first?

This sounds like a good idea. Should we do this by adding an additional CanonicalizeLanguageTag call to the top of ApplyOptionsToTag? If we add this additional call, does it remove the need for the existing call, or do we need both?