Nice seeing you picking up the topic. 
The connection to HoG may have been far fetched but it is still an idea I found worth sharing.
It was not my intention to merely replace HoG with Haiku running in a VM but to complement HoG and Haiku. To appreciate this picture, let’s recap to pros and cons of both Haiku and HoG (from my vaguely informed perspective):
For Haiku, the pros are the tasteful desktop, the management and interplay of applications, the user experience. The cons are the stability troubles you mentioned (attributed to its monolithic structure) and its large risk surface regarding security (heritage of BeOS, which was not focused on security after all).
For HoG, the pros are the stability benefits of Genode’s architecture (e.g., pluggable drivers), and a vastly reduced surface for security risks (principle of least authority applied everywhere). The cons are the lack of a desktop environment and the overly primitive user experience of Genode’s GUI stack.
The pros and cons look strikingly complementary to me (while cowardly disregarding many other aspects like device-driver support, performance, available software). This makes me wonder, couldn’t both worlds be combined so that the strength of each project can shine?
What if it was possible to use Haiku as a desktop shell (beautiful desktop) that allows for the spawning of HoG components that are executed besides Haiku, yet still displayed in Haiku windows? Technically this could be achieved by running Haiku in a VM hosted on Sculpt’s runtime, exposing Sculpt’s config and report file systems to Haiku (via VirtualBox’ shared-folder mechanism), and letting Haiku play the role of Genode’s window layouter and decorator.
Using the config fs from within Haiku, one could install and start a HoG component by adding a start node to /genode/config/deploy (as usual on Sculpt). Sculpt would take care about downloading, verifying, installing, and starting the HoG component, which would ultimately try to open a window (by talking to Genode’s wm component). The new window with its initial size appears in the list of /genode/report/window_list that is visible by Haiku. A Haiku application observes the change, creates a new Haiku window with the appropriate size, and tracks the geometry of the window as managed by Haiku’s window manager. Whenever the window is repositioned, restacked, or resized, this application writes a file /genode/config/gui_layout telling Genode about the stacking order of Haiku windows, including the window of the HoG application. The gui_layout, in turn, is consumed by a decorator that distinguishes Haiku windows from HoG windows and drives the composition of the respective nitpicker views (similar to like it’s done by Genode’s motif_decorator). The approach resembles the overlay window management idea.
Well, the end result would be the following: A desktop where HoG applications appear as being part of the Haiku desktop and user experience but running independently. Haiku (and the virtualization overhead) is not involved in the execution of the HoG application. So even if Haiku crashes, the application remains unaffected. Upon restart of Haiku, the application window would just re-appear (from Genode’s perspective, the window decorator was merely restarted).
Network-related security risks of Haiku can be reduced to zero by keeping Haiku disconnected from the network at all times and accessing the internet via Genode components only. In such a setting, Haiku asserts the role of a trusted shell (or Dom0 in Xen speak) that has full control over Sculpt’s runtime. It is not intended for running untrusted software. But it can spawn new containers where software (untrusted or trusted) can be safely executed (including VMs of course). All this power is laid into the hands of Haiku by the access granted for /genode/config/. So Haiku is not subordinated. It is in charge of controlling Genode.