This can also be just ERR_INVALID_ARG_TYPE with Iterable as the expected type..no strong feelings about it though.

For this I think the more specific error is warranted.

I know the name/value thing is already in error messages...but since we are changing error messages anyway, I think [name, value] would be easier to understand at the first glance.

The "limited to WHATWG URL" part can be left out IMO, the source of errors would be visible in the stack trace anyway... This way people don't need to change this section when they add this type of error to other APIs

[name, value] tuple would be easier to grasp..

"name/value tuple" is the WHATWG nomenclature, but I'm perfectly fine with "[name, value] tuple".

Note that at the moment input might not be exactly the same as the original input since it needs to go through trimming and String::NO_NULL_TERMINATION | String::REPLACE_INVALID_UTF8 first...we could've stored the original input, but that's for another PR to consider

Right, the REPLACE_INVALID_UTF8 is pretty edge-case, but trimming can indeed be something the user does not expect. Agreed on addressing this in a separate PR though.

In that case, why not just use 'ERR_INVALID_ARG_TYPE'?

'ERR_INVALID_ARG_TYPE' has the following templated message:

The "FOO" argument must be of type BAR.

In this case, it is not the question of what type the argument is, but whether it is defined at all.

Maybe surround this with quotes or backticks? The original error message uses backticks.

It's quite rare to have an error message with backticks in it (most error messages use double quotes). Here are a few alternatives:

1. Value of "this" must be of type %s
2. Method called on incompatible receiver of type %s (V8-inspired)
3. Method called on incompatible %s (SpiderMonkey-inspired)

Choice 1 SGTM.

I think undefined should be in the message here..otherwise if the user makes a mistake and passes an undefined, there is no way to know if it is an undefined or just an empty string.

It's a bit weird to put the verbs in separate places...maybe the must part can be left out in the error message format and written here?

Or maybe err instanceof code.constructor ?

I don't know about this one, I'm generally not a huge fan of instanceof checks due to unreliability across different V8 contexts, and it is quite possible that WPT's testharness.js uses the error name string check instead of instanceof.