Can the overlap between Duration instances and Duration Records be eliminated?

[gibson042]

Copied from #2281 (review)

Both Duration instances and Duration Records have the same set of immutable fields (with an extra branding field for the former), and the spec provides no internal guidance about when to use one vs. the other, resulting in muddled treatment¹.

I think Duration Record should be eliminated altogether, or else Duration instances should be refactored to have a field containing a Duration Record rather than duplicating its fields.

Footnotes

1. Temporal.Duration.compare and Temporal.Calendar.prototype.dateAdd include surprising examples, and the apparent pattern of DifferenceTemporal… operations returning Temporal.Duration instances vs. other Difference… operations returning Records or in some cases mathematical values is an extremely subtle one and appears to be wholly undocumented. ↩

[ljharb]

I love either of those outcomes.

[ptomato]

I believe we had this distinction so that nobody would be tempted to observably call methods on Duration instances in internal algorithms, similar to what we did with the other types. I do like that separation because it is clear that if you have a Duration Record, it should never be user-visible.

Also because for a long time it wasn't clear, at least to me, under what circumstances OrdinaryCreateFromConstructor and therefore CreateTemporalDuration could throw.

The use of Duration instances internally in the newly-added DifferenceTemporal... operations is something I personally don't like, but the amount of deduplication enabled by those operations outweighed the disadvantage for me.