I know that the way I compile TurboSphere with MSVC, it does not use CIL. I think it doesn't anyway. It outputs object files, which the linker links to make a binary. I could be wrong, if the object files are CIL. In which case, the Visual Studio linker should, somehow, be able to take both the CIL object files from a TurboSphere plugin, and the CIL output for a Sphere Studio plugin, and make a mixed library that contains the code for both. But again, I've never heard (and I've looked) of such a thing being done. In fact, I think (and am more sure that) such a thing is possible for any two languages supported by the GCC, since the object code is output by each language front end to be processed by the single backend, but I can't seem to find anything about that, either.
I think I'll get some MS C#, and see how it works. If this even just worked on Windows, that would be amazing. Radnen, is the code for a Sphere Studio plugin available online? Even an unfinished one. I would like to experiment with this.
Making a single routine handle, say, opening a filetype, when the editor and the engine ask, is another story. I'm not worried about that yet. Even if that isn't possible, the same end result can be achieved.
Another problem is that a TurboSphere plugin needs to also have C++ code internally. The plugin interface, while only given C-linkage, gives the engine addresses to C++ functions. A plugin needs the STL library to talk to V8, and the plugin directly calls V8 functions and V8 quite extensively uses templates. The reason I could implement the plugin system so fast was that I unloaded all the heavy lifting onto the plugins, the engine does very little now. It mainly starts up a V8 context, compiles scripts (which could easily be a plugin's responsibility), and intializes plugins. To change that, I would have pretty much abstract away the interface to JS. Which is an immense undertaking, and begins to tempt that black hole of total extensibility.
EDIT:
Apparently, we aren't the first to seriously wonder.
http://blogs.msdn.com/b/texblog/archive/2007/04/05/linking-native-c-into-c-applications.aspx. And apparently, the MSVC linker is the answer? I'm going to give it a shot.
If anyone else wants to cast their lot in, I created the plugin getkeystring just for testbed scenarios (like this, but I actually expected the first use would be for making plugins entirely in other languages, not for experimenting with kind-of-fat binaries).