The two primary pieces are
mod-host is the part that is responsible for the running audio system. It loads, connects, and runs the plugins via the JACK audio interface.
mod-ui is what presents the web interface and is what organizes pedalboards and settings together.
mod-host itself has no concept of a pedalboard as you can see in the mod-host API. Pedalboards are an abstraction made available by
mod-ui and they are basically files on disk that contain the state of the pedalboard graph.
mod-ui reads that in and then makes the correct series of connection, param setting, and midi mapping calls. This is great, because it means we can bring our own abstractions.
Conceptually, we just need to start writing bits of code that will build and manage the running state of the system for whatever we define those states to be. As a first step, prototypes could be made with Python/shell scripts that power users could use to build, manage, and run this component / module / nested pedalboard / pedalboards-within-pedalboards / pedalboards-all-the-way-down concept. Of course, most users would require or benefit greatly from a UI, which would be a great deal more work, but getting to a proof-of-concept point for this meta concept seems like it would be attainable in a hack day or two.