By introducing another layer of abstraction we will most probably decrease the performance of all languages[1]. That is, since the universal interface to, given your example, the Sablotron XSLT library is the API and Perl, Python and PHP have internals different enough that there would have to be a certain amount of glue and translation work between the structures of the extension layer and the internals of the interpretter.
It should still be possible to come up with some guidelines for writing a single extension that supports multiple scripting languages. Especially for something like Sablotron which isn't that complex. You feed it some XML and some XSL and it spits back a result. Most of the work in writing the extension is figuring out how the user-visible API should look and then translating that API along with its function/method calls and argument type mangling to whatever the thing that is being glued is expecting. Note that I am not talking about runtime binary compatibility here. I am talking about source compatibility where potentially big chunks of code would be very different across the different languages. In an approach like this I don't see a performance issue. It is more of an education issue actually. And with a bit of effort I bet we could come up with enough common ground, or at least some nifty macro tricks, where people wouldn't feel overwhelmed by the task of supporting multiple scripting languages when they sat down to write some new backend library. Perhaps it would be a good experiment to take some really simple thing and write Perl, Python, PHP, Ruby, and Tcl extensions for it and compare notes. See where the overlap is, see where the biggest divergence is, and figure out if some of that divergence could be eliminated with some clever tricks.
[1] The situation where you could perhaps increase performance is the converse of what is being suggested. Presumably, if it is in the interest of language developers to have a unified extension layer, then the point of different which language developers want to maintain with with other languages is the syntax/grammar of the language.
As I see it, along this line of thinking it makes sense to look at the feasibility of a language system (internals and extension layer) which handles plugable scripting engines. As such, the majority of work which goes into language development can be concentrated while allowing, to the users, automony in their choice of language.
Sure, but now you are back on the holy grail and CLR stuff again. Baby steps... -Rasmus