19.2.3.5 Function.prototype.toMethod (superBinding, methodName = undefined), step 1:
> If func is not an ECMAScript function object, then throw a TypeError exception.
But built-in function objects may be implemented as ECMAScript function objects (cf. 9.3), so it may make sense to explicitly exclude built-in function objects from Function.prototype.toMethod() to ensure consistent behaviour across implementations.
The ECMAScript function requirement is there because we don't know anything about non-ECMASript functions and if or how they might represent super bindings.
toMethod should work fine with built-ins that are ES function objects. Bot note that currently no built-ins are specified to use super because super is a mechanism of the ES language and we don't know whether a compatable mechanism is available for non-ES functions.
What we probably could do is treat non-ES functions just like ES-functions that don't have a super or name binding. Basically just structurally clone them.
(In reply to comment #1)
> toMethod should work fine with built-ins that are ES function objects.
I'm mainly concerned about cases where toMethod() works in one ECMAScript implementation and not in a different one depending on how implementations define their built-in function objects. This just calls for trouble.
>
> What we probably could do is treat non-ES functions just like ES-functions that
> don't have a super or name binding. Basically just structurally clone them.
Hmm, I'm not sure whether that works in general resp. is an acceptable solution for implementors. It should possibly be discussed at the f2f.
fixed in rev23 editor's draft
updated to explicitly allow with exotic built-in function objects.
fixed in rev23 draft