I'm specifically referring to running them as a single unit, with a single message loop and implementing a single responsibility point for important context/thread issues so it can act as a single javascript host environment while providing the API's and bindings of them combined.
I keep having the itch to integrate closer and closer here. The WebKit and varied APIs brought in for browser usage are a pretty awesome yin to Node's file/stream/net/data/etc. yang and it seems realistic to make them one in the same. I've spent a good chunk of time with the internals of Node and of Chromium and CEF and I feel I have a pretty good of what's involved (while at the same time being a comparative noob as I have have a webdev professional background where which has different concerns most of the time).
Generally speaking, they're fundamentally compatible in the sense that the most sensitive/important component is V8 and the excruciatingly carefully curated environment and context(s) exposed to JavaScript. Chromium offers are lot more beyond that scope but it's also largely stuff already ignored and less useful when you get to the point where CEF is (pare it down to the stuff specifically for rendering the webview and providing bindings for JavaScript to do stuff) and this is about the same point we want for node. Using Node, we'd want probably ideally pare it back some more to remove any extra functionality that Chromium provides which node already does better, but that will be limited as Chromium needs a lot of specific stuff to support heavy native dependent tasks like GPU rendering.
The way the surrounding and supporting environment is constructed is different between the two and speaks to the different purposes they serve, while at the same time remaining fundamentally compatible because they are limited by the same fundamental requirements and limitations. You see the same object wrapping, refcounting, thread limiting, etc. as these are mostly limitations/conventions imposed from V8 on everything else. It's a safe bet that this biggest barrier to cross-implementations with other types of applications is basically non-existent here.
The most useful and likely implementation of this (as I can tell from my limited mastery of the subject) would have Node's normal processes uses as the application baseline. The lifecycle of node is built around the perspective of a programmer using it as a tool to build other tools applications, and this is much more flexible and adaptable than the angle Chromium comes from. This would also involve some curtailing of some of Chromium's extraneous activities (which I think CEF has already mostly taken care of anyway) with the ultimate goal of keeping its responsibilities tied to tending the webviews, the minimal native window the web views live on, and I/O directly needed or requested in service of webview actions.
The likely tricky parts come in handling their somewhat different usage of threading. Node doesn't really have the concept of a UI thread because it's not necessary, but I'm pretty sure that doesn't matter except that any thread checks will have to be implemented on anything from the traditionally Node side that gets the go ahead to venture from the basement into the UI .
I would imagine that the simplest route for ease of implementation and security is in not adding too much extra goodies to anything in the webview/ui context. As it stands, Chromium already does all its cross-thread communication via message passing, so a lot of mind has already been paid to being careful. It will more be able just making sure Node is set up to use those same paths.
In my mind, ideally we could also make some extra use of Proxies/WeakMaps that are now making a strong showing in recent versions of V8 to allow us to implement safe-but-still-fluent pathways between the realms to facilitate the real fun: mixing and matching capabilities from both worlds. Using node's mastery of data to fuel powerful and attractive UI's, or the massively awesome tight integration of many types of media that WebKit/Chromium provides for building dynamic and interactive set pieces, but integrated with using Node's expressive data interface in propagating amongst many users across varied interfaces.
I'm curious about learning what may be the gotchas here that I may not be thinking of. I don't think it will necessarily be easy, but it seems to be well in doable range, especially with CEF as a starting point for Chrome, being already stripped down to the necessary pieces.