Support UTS 35 long unit identifiers in Amount construction and conversion?

UTS #35 Unit Identifiers distinguishes core unit identifiers (e.g., "foot") from long unit identifiers (e.g., "length-foot"), which prefix the core identifier with its category. CLDR's conversion data uses core identifiers. But the long form seems to be what keys the unit display names in CLDR locale data (<unit type="length-foot"> in CLDR's common/main/*.xml, and likewise in their cldr-json, e.g., en here). 402's sanctioned single unit list uses only core identifiers.

I believe we haven't discussed yet whether Amount should handle such unit identifiers during unit conversion. The question is whether conversion and even construction should understand such units as equivalent to others.

To be concrete:

new Amount(7, "length-foot").convertTo("inch").unit;      // "inch" or "length-inch"? throw?
new Amount(7, "foot").convertTo("length-inch").unit;      // "inch" or "length-inch"? throw?

Even just constructing a new Amount raises the issue:

new Amount(7, "length-foot").unit;                        // "length-foot" or "foot"?

Some options:

• Normalize to core identifiers whenever possible. Long IDs are accepted at construction time and as arguments to .convertTo, but after construction, .unit would contain only the core form. (Units that don't correspond to any CLDR unit are acceptable, and wouldn't be normalized because there would be no basis for normalization.) This is simple, keeps .unit directly usable with Intl.NumberFormat.
• Normalize to long identifiers whenever possible. Analogous to the previous option, but we might run into trouble with Intl.NumberFormat.
• Respect the source: After .convertTo, .unit holds the string of the original Amount value.
• Respect the target: After .convertTo, .unit holds the string that was passed in, and the constructor likewise preserves what it was given. But with this approach, new Amount(7, "length-foot").toLocaleString() would need special handling, since Intl.NumberFormat throws on long identifiers.

Start by comparing the construction and convertTo examples with UTS #35, CLDR conversion and locale data, and ECMA-402's sanctioned unit identifiers. Define the expected unit value and formatting behavior for long identifiers, including toLocaleString; done means the project has an agreed, documented behavior for these cases.