The Calendar draft document doesn't delegate compare() methods to the calendar because in most cases it doesn't seem necessary. You can use the ISO-valued internal slots because no matter what calendar a date is projected into, it doesn't change whether it is before, after, or equal to another date.

However, with the data model adopted in #391, this doesn't necessarily hold for Temporal.MonthDay anymore. It still does hold in the case where the calendar can assign one RefIsoYear to all its MonthDay instances (as the Gregorian calendar does, where we can pick any leap year as RefIsoYear such as 1972 and as long as we always use the same one, comparisons will still work.) But in lunar calendars, such as Hebrew, it won't work.

On the other hand, if we tried to fix this by reading the fields with Get, then that wouldn't work for calendars such as Japanese with eras (where 1 Reiwa comes after 31 Heisei, you'd have to know to take the era into account) so then all comparisons would have to be delegated to the calendar.

Is it better to delegate all comparisons to the calendar (more burden on calendar implementors), or only Temporal.MonthDay.compare() (making things inconsistent)?

Note: currently in the spec, comparisons read internal slots, whereas in the polyfill they perform a Get. So this is inconsistent and needs to be resolved either way.