Aside from the exception noted in #390, I've convinced myself that the ISO-based data model agreed in #290 is sufficient for Temporal.Date, Temporal.DateTime, and Temporal.YearMonth. However, we need to think more deeply about the data model for Temporal.MonthDay.

We cannot simply map a calendar month onto a Gregorian month, because calendar months can shift alignment each year.

We also cannot simply interpret the numeric month field as being in the specific calendar system, because leap months can share the same numeric month.

Possible solutions:

1. For the purpose of the data model, define isoMonth and isoDay as being indexed according to ISO year 2000 (or year 2020, or year 1970, or year 1).
   • For example, if you wanted to express Shevat 25, you would encode it as (IsoMonth, IsoDay) = (2, 1) since in the ISO year 2000, Shevat 25 landed on February 1.
   • Issue: not every month occurs in every year in the Hebrew calendar.
   • In Gregorian-like calendars, the month and day can be passed through efficiently.
2. Use calendar-specific month/day and allow the month field to be non-numeric.
   • For example, if you wanted to express the 25th of the 4th leap month in the Chinese calendar, you would encode it as (Month, Day) = ([4, true], 25).
3. Use calendar-specific month/day and add an [[IsLeapMonth]] slot.
   • For example, the above would be encoded as `(Month, Day, IsLeapMonth) = (4, 25, true).
   • The [[IsLeapMonth]] slot would be meaningless to the Gregorian calendar, even in February.
   • Unclear whether this single field is sufficient to handle all possible user-land calendars.
4. Use isoMonth/isoDay and add a [[RefYear]] slot.
   • For example, Shevat 25 could be (IsoMonth, IsoDay, RefYear) = (2, 1, 2000).
   • It could equivalently be encoded as (IsoMonth, IsoDay, RefYear) = (2, 20, 2020).
   • Advantage: addresses calendars where not every month occurs in every year.
5. Other?