https://github.com/tc39/test262/blob/master/test/intl402/DateTimeFormat/prototype/resolvedOptions/hourCycle-default.js is currently failing in SpiderMonkey, revealing a potential spec issue.

Reduced test case:

function hourCycle(hour12) {
  return new Intl.DateTimeFormat("en", {hour: "numeric", hour12}).resolvedOptions().hourCycle;
}

print("default:", hourCycle(undefined));
print("hour12=true:", hourCycle(true));
print("hour12=false:", hourCycle(false));

Returns in SpiderMonkey:

default: h12
hour12=true: h12
hour12=false: h23

But in V8 (and per current spec):

default: h12
hour12=true: h12
hour12=false: h24

InitializeDateTimeFormat, step 30.d for hcDefault=h12, computes hc=hc12 for hour12=true resp. hc=hc24 for hour12=false.

But when we're consulting CLDR's supplementalData.xml for "US" [1], the preferred hour formats are either "h" or "H", which means either "hc12" or "hc23". So "hc24" is likely an unexpected result for US, because "k" isn't listed in the preferred hour formats for that region. (See [2] for "h", "H", and "k".)

[1] Adding likely subtags to the "en" locale results in "en-Latn-US".
[2] https://unicode.org/reports/tr35/tr35-dates.html#dfst-hour