Just to throw my view on some of the topics cropping up here:
Exporters - "depending on third parties" is unavoidable with pretty much any software development. Native engines depend on the OS and drivers instead of the browser, and those are rarely perfect either. Driver bugs can mean games glitch up or crash, and there is almost no reasonable way of investigating it other than buying the affected hardware, setting up a system to use it, installing a particular version of the driver, debugging it, then coming up with a (sometimes convoluted) workaround - if the problem even makes sense. This applies to both mobile devices and desktop components like graphics cards. Our old native engine in Construct Classic also depended on DirectX which needed a separate installer which was a big pain in the ass for everyone.
Further, portability becomes extremely difficult with native engines. Several competing tools with native exporters have really patchy support for features across the different exporters. Some features may simply not transfer to other platforms because they are not supported, or they work differently, or the developers never got round to porting it there. It also massively slows down development since a lot of new features need to be written N times for N platforms, with N times as many bug reports, and the extra challenge of maintaining compatibility between N implementations; with C2 we only ever need write it once. Third party plugins in particular rarely support even half the supported exporters, only covering whatever platforms the plugin developer happened to have the SDKs set up for. HTML5 is really good at getting stuff to just work across platforms. Browser support does mean there are occasional gaps, but it's all based on standards and browsers are improving really fast, so gaps get filled in.
I truly believe that native exporters would mean we end up doing nothing other than maintaining a bunch of parallel codebases with no time to do anything else, with games that cannot be ported between platforms, and no fewer dependency issues than we already have. I think it's another case of the multiplayer engine feature, where people suggesting it imagine it working out far better than it will in practice.
Related to that is wrapper support - we've already dropped support for all non-browser wrappers. The remaining "wrappers" are actually true browser engines that are pretty much completely compatible with the existing engine, so it's more or less a finished job. I'd also note that most browsers manage regular updates without breaking the entire internet, so I'm sure apps will be fine too.
Also related to that is performance - I'm willing to profile any .capxs that people send to me which have performance issues, and see if there are any bottlenecks in our engine. Most of the examples I see though are simply extreme cases of ignoring the performance guidelines and designing an incredibly inefficient project, or they otherwise exceed the hardware capabilities of the advice. Rarely is the C2 engine the bottleneck. In particular WebGL allows native-grade use of the GPU, so if your game is GPU bottlenecked, a native engine will not perform better. Modern mobile devices are also approximately as powerful as a cheap laptop - or more powerful - so if your game doesn't run on mobile, it probably won't run on low-end desktop systems either, and both types of system have plenty of power to deal with a well-designed game.
3D - I've said it before and I'll say it again! It's a whole different product idea IMO, and we're going to stick to a 2D tool for now.
As for our plans for 2015, there are a lot of good ideas in this thread, but they're not really possible until C3, which we plan to start addressing this year.