Please do not use String::fromLatin1 for ASCII literals. We need to remove this from existing code and stop adding it in new code!

Happy to take out the fromLatin1, but it won't compile without the StringView (calendarOptional.value() is a Vector<Latin1Character, maxCalendarLength>).

Best idiom for comparing a Vector of Latin1Character with a string constant is to call the equal function that compares two spans, something like:

Using StringView brings branches for handling of 16-bit characters into play, unnecessarily.

Done.

I don’t see any code passing nullopt for this third argument. Are you sure that code path is exercised?

JSValue has a distinct zero value that is distinct from JavaScript null and undefined, so it can be used for a JSValue that might be omitted, passing zero value as appropriate. And often in other JavaScript contexts we can use null and undefined instead. Do we really need to use std::optional here? I can’t find where it is used and for what.

Typically when called from JavaScript, omitted arguments are represented with an JSValue of undefined.

Also, the argument meaning isn’t clear here without an argument name, so we should include that name here.

I think the reason it was optional is that it's used that way in a future commit (I originally had a big monolithic PR for these changes and what I'm submitting now is the result of splitting it up), but using the zero value for JSValue seems fine.

I suspect we might want to use undefined rather than the zero value; I’d probably have to see more of the future code to know if that’s a good choice. But I also would have probably suggested making it non-optional and then add the ability to leave it out in that future commit.

optionsValue is now just JSValue, so if (optionsValue) means checking if optionsValue is not zero value.
But I think what we should do here is checking if optionsValue is not undefined (or null) ?

If my comment makes sense, we should add more tests to check this behavior

I think you're right, checking for undefined makes sense, because that's what would be passed in from temporalPlainYearMonthConstructorFuncFrom if no options argument was provided. I changed it. I also added stress tests for null and explicit-undefined options objects.