Been thinking a lot about layout and end-user programmability. This grid container lets you break free of the cell layout, while what is inside the grid is still Observable reactive cells. When the grid is changed, the container rewrites its own source code to reflect your changes, patching the runtime live, so in a sense, you are programming but not through a textual interface. If you then serialize the runtime, the result remembers the changes.
Going further, each audio component it wrapped in sticky which does the exact same trick for “views”. A view change detects its value has changed, and rewrites its own source code to make persist the value change as a code change to the cell’s internal definition.
Now putting it all together, the way exporter-3 works is by scanning the runtime and reserializing, so the fact the runtime definitions have changed means it now picks up those user changes when creating forks. TADA 
solving the problem of making UI widgets persisted. As exporter is a normal Observable cell, its placed inside the DAW grid component so you can access the forking functionality within something that now resembles a custom UI laid out the way you like it.
It works reasonably well on Observable platform, including Notebook 2.0, but it shines on my own framing because it can offer more shortcuts at the host level.