> Seems like a much simpler approach that would minimize code duplication, though.
What you're describing is the existing solution in master. There are a number of problems with it, but you've inspired me to revisit the idea of making minor modifications to patch what's in master to work for everybody.

Basic problems with the existing solution in master:
* It's possible to fool the parser with shenanigans. There is currently a hack in place to block any ')' character in the parameter string, but this incorrectly rejects some valid invocations.
* A dynamic function's toString must show that the function has a name of "anonymous". However, there should be no symbol that binds the name "anonymous" to the function. This becomes an issue when you try to solve v8:4958.

Here's a test case that tests for all of that:

```
assertThrows(function() {
  Function(") { function a(", "}");
});
Function("a=(1)", "");

var anonymous = "global";
var f = Function("return anonymous;");
assertEqual(f(), anonymous);
var g = eval("(" + f.toString() + ")");
assertEqual(g(), g);
```

I'd like to investigate solutions to each of those problems independently.

* After parsing, check token positions of either the last parameter or the first token in the body to make sure there are no shenanigans going on.
* Give special instructions to the parser or someone else to not create a binding for the function name.

I still need to do some research to figure out how exactly to go about doing those two things, but I think the strategy deserves some attention when compared to all the scary code duplication currently in this CL.