Function arguments are named and represented inconsistently in the description and the initial solution ( and possibly other places ).

I'd suggest calling them by the same name everywhere, and representing specifically the f argument ( the first one ) as a string, which ATM it is, and not as a function ( which ATM it is not ) in the description examples. I haven't checked the test headers, but the same goes for them. Should you decide to make the first argument a function, then of course represent it as a function everywhere.

It appears the x parameter is the middle of the output grid. That middle is of course defined by two coordinates, and it would seem its y coordinate is also defined by x.

Is this correct; is this the best way to define the middle of the grid ( I think not ); and if correct, shouldn't this be described more fully?

Use appropriate datatypes. The function argument could be a function, unstringified.

This would also facilitate translations into languages that do not have eval, like Haskell; I would like to translate this into Haskell, but I'd have to write a parser from string to function and put it in Preloaded ( that's what it is for ), because writing a parser is a bit outside the scope of this kata.