A metaplugin can use other metaplugins as components. This is possible because from the host's point of view, a metaplugin is simply a Freeframe plugin, like any other. No special procedure is required; nesting occurs naturally when you include one or more metaplugins in a project, and then export that project as a metaplugin.
A metaplugin can use a combination of metaplugins and ordinary plugins, e.g. you could make a metaplugin that uses a mixer plugin to automatically crossfade between two metaplugins.
There's no limit on how deeply metaplugins can be nested. Each level of nesting results in some additional overhead, but the amount is insignificant compared to the overhead of the ordinary plugins that are actually doing the work.
Nesting lends itself to an object-oriented approach, in which simpler metaplugins are used as building blocks in higher-level metaplugins. This encourages iterative composition, and distributed creation. For example, if I make a metaplugin that does something you like, and send it to you, you can add value to it, by using it inside one of your own metaplugins.
Nesting can also be used to create modulations more complex than FFRend's built-in oscillator waveforms. For example, suppose a metaplugin exposes a parameter's modulation frequency as a metaparameter. If the metaplugin is nested within another metaplugin, the top-level metaplugin can modulate the frequency. The same technique applies to pulse width.
Nested metaplugins can be embedded, but only if all the plugins at each level are copyleft, i.e. have the string "copyleft" in their Author/License information (see exporting metaplugins). For example, if I send you a copyleft embedded metaplugin, you can embed it inside one of your metaplugins; if your metaplugin is also copyleft, it can be embedded by someone else, and so forth. When the top-level metaplugin is loaded into a host, it unpacks itself recursively.