Oh, and 
Arima - you argue "there's too much uncertainty", but with a native port you'll have uncertainty over supported features instead. As I said before, a native engine is not going to be a magic bullet where everything works perfectly, it will tradeoff performance for other porting incompatibilities.
I also absolutely cannot see why examples of single bugs like memory management is an argument for the extraordinarily expensive and time consuming development of native engines. It is *obviously* much easier to fix those problems first before even considering it. This is an ongoing work in progress, but we will get there.
With modern devices with an up to date browser and OS, performance is already outstanding: as I said before my Nexus 5 can outperform some of the desktop machines in our office on some benchmarks. There's an argument to make a native engine to support older devices, but a native engine could easily take so long to develop to maturity that the next generation of phones and software updates would have already filtered down and far reduced the problem. This already happened with desktop. I dread the idea that we spend a year holding up everything else to write a native engine, and then by the time we're done HTML5 performance on mobiles is not a problem. What a colossal waste that would be!
Actually you don't have to fix those issues.
In five years, Moore's Laws and browser-side performance improvements will fix those issues.
I still find it bizzare that my web browser itself (not related to Construct 2) takes up far more memory then it did when I only had a 1 GB RAM desktop. Sloppy browser design.