Gunther's points are good ones, Russell. Should definitely be taken into account.
I was thinking about easier ways to deal with vararg issues, and I think I thought of one. Instead of using getArgToFunc, on the front end in outputSchema, you can just verify that the schema is homogenous and concat-able (i.e. all strings, all longs, whatever). If you want to be really fancy, you can find the code that defines whether or not a type is coercible and base it on the first argument (i.e. string long long could be concat-able as all strings).
I've realized now that the existence of getInputSchema largely makes the getArgToFunc construct irrelevant except in the case where you need frontend specific information passed to the backend via the constructor based on the type of the input (which is not the case here).
Then on the back end, you lazy initialize based on the getInputSchema schema. You can constructor a concatenator based on the Schema which actually does the concatenating, and then just run every argument against it (i.e. if you detect String, String, String you initialize a StringConcatenator). There are a couple of ways you could design this, and this is where you could take into account coercion rules.
Bam, no deep changes necessary to support varargs.