Personally, I quite like the idea of using an agnostic scripting language to make plugins (I suggest python - it's an alternative to lua that's performatic, supported everywhere, widely known and easy to pick up).
With all plugins written in such language, even if it were to be a custom language developed by Scirra, a tool could be created to convert said plugins to the native language of the exporter, maintaining the plugins compatible across runtimes.
Scirra maintains an open forum, and we're free to discuss competitors products (which shows the level of confidence they have in their product), and I also know Ashley would never diss a competitor (due to potential issues that could arise), but since I'm a regular user, I can say whatever I want, so here goes:
I've used clickteam's products since Click'n'play, and I own MMF Developer 2. Besides the slow development and lack of features (I know Nifflas is struggling to make CT implement things like modularity, code reuse, complex behaviors and a lot of cool stuff, by the way Ashley, you should look at his suggestions for MMF, since they're all gold), the recent craze with exporter creation is a living example of what Ashley is talking about:
Since the plugins are coded in C++, and the SDK isn't good (at all), there are few plugins being developed, and nowhere near the speed we have here - the barrier to entry is too high. They had efforts to improve this since MMF1.5, with tools to create boilerplate code, new SDKs that simplify development, to no avail. The differences between compilers are too great, and you end up having to create a SDK for each IDE.
Besides that, since plugins are written in their native languages, a new SDK has to be written for each exporter (and it takes a long time, most SDKs only come out months after the exporters), and the plugins themselves have to be remade for each new exporter. This means that the product ends up full of holes - there's a plugin for flash only, another that is hardware accelerated, some other for iOs only, and so on - consistent plugins, that is, ones that work across all runtimes, are extremely rare (mostly only official extensions) - and we're not even touching the issues that came up in the transition from MMF 1.5 to MMF2 - many plugins were never converted, because they were closed source.
In conclusion, the best bet (in my opinion) for the plugin issue across exporters would be
- A unified language for plugin creation, that would enable an automatic plugin conversion
- A contract that only allows the user to create a plugin if they agree to cede some rights to Scirra (in the case of standard and free licenses, business licenses should be exempt from this) - this would allow Scirra rights to convert plugins automatically without asking for permissions
- A unified "store" or feature to enable people to download and update plugins (even pay for them) - the rationale is, once C2 becomes popular (and this is already happening), a ton of communities will rise and start creating plugins. This is something that happened in Clickteam, and results in a nightmare for common users, that have to hunt around periodically for latest versions, often can't communicate with authors in case of bugs, authors lose source code (this left a lot of plugins essentially unmaintainable), and some plugins are only found in weird forums.
This would obviously necessitate a lot of time spent on planning within Scirra, since it concerns the future of the company, but I think it's well worth it, even if it puts some features on hold (though please, please make containers, I really want them).