If you use it identically to the Function plugin, it's probably OK. But I don't know, the bigger problem is that it's unknown which circumstances it works exactly, so it would be tough to document it and I don't want to have to support it if someone uses it in other cases. E.g. if someone uses it in some other way, then files a bug because it's broken one way or another, that's exactly what I want to avoid. It's meant to be a single-purpose shortcut that nobody else knows about.
One of the big problems with the C2 SDK is basically everything is public and people go nosing around undocumented APIs and relying on them. This is pretty bad for us, especially if people start asking us to document or better support random hacks in the engine that were never meant to be used anywhere else. I mean, what next - is someone going to start fiddling with the WebGL batching engine and asking us to document what various command parameters are for? It gets pretty obscure in that part of the engine, mainly because a bunch of stuff is recycled and repurposed to relieve GC pressure. Nobody's meant to care about it, but in theory someone could end up writing a plugin that uses all that.
In the long term it also risks making the entire engine inflexible - if we can't change the code without breaking some random third-party plugin, we could end up struggling to make any changes. For example it could end up that we can't ship a 2x performance optimisation, because several third-party plugins ended up depending on a particular algorithm that we used. This could well be the case with fast triggers: we might be able to speed them up further by making its restrictions even tighter, which is OK with the official function plugin, but not OK if it was a documented general-purpose API that we have an obligation to support forever, or put through a lengthy deprecation-and-removal process. The end result could be everyone's games are stuck running slower and we can't make optimisations to improve it.
By the way, this is why for the C3 SDK we've taken a consciously different approach. There is a much more focused (and limited, at first) set of APIs available. We hope to broaden it out over time, of course, so it can do everything C2 did and more. However this takes time. These APIs will be much better designed so it still allows flexibility in the engine, will be comprehensively documented, we'll support them with bug fixes etc., and we will provide backwards-compatible support for the foreseeable future (unless we put them through a deprecation process). In the long run this is much better for everyone, but in the short term puts us under pressure to work on various API features (like the text rendering API I just filed an issue for). We'll do our best to keep up with that.
Finally one extra thing to note: the C3 runtime will in many cases use identical APIs to the editor. For example IWebGLRenderer will be identical in the editor and runtime - and it will actually be backed by identical JavaScript classes, since we can share editor code with the runtime. Hopefully this makes it a lot easier to develop plugins, since the editor code can be shared with the runtime. For example we already have a particle engine in the editor for the live preview feature; when we come to port the plugin to the C3 runtime, we'll literally copy-paste that to the new runtime, saving a lot of work.
Maybe I should've written a blog post about this