Right now our overload resolution generator will generate pretty bad code for a case like this: void foo(optional sequence<long> arg); void foo(long arg); In particular, it will spit out a zero-arg case which has all the sequence conversion code, then a one-arg case which has it _again_. One possible way to solve this: 1) Add a isKnownMissing argument to getJSToNativeConversionInfo. Use it in the various bits of that method. 2) Pass in this argument from CGArgumentConverter (which will need a similar argument). 3) Pass _that_ in from CGPerSignatureCall, which will need a "known arg count" argument, in addition to the existing argConversionStartsAt. 4) Pass _that_ in from getPerSignatureCall, which will need the corresponding argument. 5) In the "only one overload matches this argcount" case, pass argCount to getPerSignatureCall as the number of args we have.

Boris, is this impacting something that would mean we should fix it sooner than "someday"?

At the moment, there are no non-test bindings that hit this case, assuming I got my codegen instrumentation right. So "someday" is totally fine.