Maybe this could have been handled better, maybe not. But I certainly don't hold it against Ashley.
When this bug first occurred, he filed his own report (which collected dust), and was active on the report this thread links to (which was also largely propelled by someone called Jerry Jongerius, who has probably done more legwork on profiling and tracking this bug than anyone, and who, as far as I know, has no affiliation with C2 or Scirra). Ashley also created and refined the sbperftest for evaluating jank, framedrops, etc., with a specialized demo run of space blaster. Oh, and of course, he also develops C2 and somehow finds time to be active on the forums. He may even sleep.
I, on the other hand, spent 5 minutes writing a thread, which just happened to take off. BTW, neither of those twitter posts are mine; one is from Scirra (Ashley) itself. The thanks is largely due to the C2 community, which, as always, rose to the occasion.
I think at the beginning, we all underestimated this bug, and sort of assumed that it's severity would ensure it would be fixed quickly. It wasn't, and while the current stable is much improved, we're still trying to stave off future regressions.
The main goal in mind for me is to indicate to google that display quality is not a trivial issue for Web 3.0 (Browser-as-OS). There needs to be better internal testing to ensure that regressions like this don't make it into stable versions in the future...and that they are fixed quickly if they do, as with security issues and other major gaffes.
The best thing for this is competition. Ironically, the next contender may be everyone's old frenemy Microsoft. Reading between the lines of their recent announcements, I think it's very likely we may see something similar to node-webkit/crosswalk built around Spartan, where we can package apps with a high-performance browser runtime seamlessly and across multiple (MS) platforms. On windows at least, this would be a welcome addition.