Thanks for jumping in 
appMobiSam!
Our engine is canvas-only, it doesn't do anything visual with the DOM apart from draw to the canvas so reflows shouldn't be a problem.
Also, surely the overhead of stringifying from the webview to native isn't more than the overhead of stringifying to the other context then calling eval()? Do you have performance figures comparing the two? I didn't think there would be much difference between them, but then again WebGLGap didn't work out so well :) Anyway, that's why I've been thinking a single context approach makes much more sense, but that's just from our point of view.
Most of the difficulty of porting comes from lots of little things, really. There are already a lot of games in Construct 2 and even dropping little features breaks some people's games. For everything to work the game needs to know the image dimensions, but only the directcanvas layer needs the actual image. My first naive port of everything-in-directcanvas didn't work, presumably because there are a few DOM references that throw it off. Besides, the three input plugins assume a full DOM is there, Browser and Webstorage assume they're in a real browser, and Button and TextBox are real DOM elements too. DirectCanvas didn't look like it had anything to draw text with, which is no worry - we already overlay a 2D canvas for text rendering in WebGL mode - but then our renderer has to be half-and-half DirectCanvas and WebView. If DirectCanvas doesn't support patterns or texture co-ordinates we have to do something different for tiled background. etc. etc. We'd love to get it working but it seemed to be a lot of work (I never thought I'd have to munge some of the engine in to another context) and we're already knee deep in other projects so I was trying to persuade you guys to do a single-context version! :)
FYI our next release (in about a week) has some minimal tweaks to export an AppMobi-aware game, but it's probably not much different to what you've already done in testing.