So far there's weak precedent in JavaScript specs and broader-but-with-exceptions precedent in web specs that "is" prefixes are reserved for functions asking questions about their arguments, and we don't use them otherwise. https://w3ctag.github.io/design-principles/#naming-booleans

Examples:

• Functions asking questions about their arguments: Number.isNaN(arg), Array.isArray(arg).

• Properties asking questions about their this value: regExp.multiline, temporalDate.inLeapYear, event.cancelable. (event.isTrusted is a notable exception on the web.)

• An options argument being used as input into a spec-defined function: not sure of any ES precedents, but on the web we use new Event(type, { cancelable: true }), which makes sense to match the previous bullet (i.e. it'd be strange if you passed in isX as an argument and then had to consult the x property).

This spec is actually about an options argument being used as input to a user-defined function, which I'm not sure if we have any precedent for even on the web. But I think it makes sense to align with the general trend toward omitting "is" prefixes except in the functions-asking-question-about-their-arguments case.