Ready.
With frozen@mid80, in representing, while toggling submacros (pressing space bar, or CR/BS), a few of the combinations may red-flag, with the text "recursive" in that, signalling that they are not runnable/thinkable.
Neither practically, nor even in theory. In philosophy, resembling the set-containment paradoxes.
Could a pot contain itself, let alone containing its container pot? Similarly, a macro is not able to.
In Pascal/C, we use pointers to structures.
In contrast to macros, a reduction is not a container. Thus, a reduction does not peek through that pointer. (Implicitly equivalent, reducing to a category/tag, cf. a pointer2int vs. pointer2double).
The formal mazing of a frozen@mid80 "hierarchy" is actually kind of a directed acyclic graph (DAG), that is, any macro may point at any, as far as there is no (structural) recursion. For example, in the family-"tree" case, both your mother and your father, point at you as an offspring. Their families may converge in the old times, too.
For example, the father of the mother of my mother was an uncle of the father of my father.
If to think that as a graph, that root may sound as afore-the-graph, pointing at all the root set of the graph/DAG.
In a graph, there may exist one or more instances of any formal type (macro/submacro). A ZIP# is unique, for enumerating all. That is the question of type vs. thing. If thing1 and thing2 are both of the type macroA, they both reflect the framing & fragging of macroA, but their contexts/data may differ, as they are separate entities.
For example, even monozygotic twins who may look like identical in shape & attitude, would act differently, if at that moment, one is at the restaurant, while the other is at a lecture. The calories consumed by the twin in the restaurant, would not reflect in the blood glucose level of the other.
frozen@mid80 has two "identical" formal structures, the fork&join, as well as the f&j2. Identical does not entail identity. Thus, we may build with the two, a few macro hierarchies, that otherwise would be recursive.
That is a remedy against a few recursive structures. If all that is wantable is having/duplicating the facilities/structure of that type, having two is valuable. They necessarily differ, though. The subhierarchy of one is different than the other -- as that would be including that other.
With the SnapCircuits toy, as electric/electronic module set, any pack has a few of several types. If to build a yet other project with your set, first you have to dismantle that project tieing up your available modules. In the case of frozen@mid80, although the specific instances are not limited, the types are resembling that hardware kind of limitedness concern, if to modify for specific uses.
Any type/macro is usable as a few different submacro instances, within that application.
For example, both the location b2 and b3 may be of the type fork&join. No need for f&j2.
That is not doable with hardware. If a type were exactly like hardware, we would have only a single example of that for an application. In a toy-train railroad, a track is not both here & there.
The macro definition (type) is static. The specific instances are dynamic replicas. The former is hardware'ish.
The distinction of type vs. instances (of that type), may confuse, too. For example, the NN73-2 is not a loop. We would have to fold b1 & b8 together, to form a loop. Could we mount this/that macro to tie the two (from b8 to b1) together? No. Trying to form a loop, is about confusing the static (template) vs. the dynamic (virtual).
That may seem as if a Zeno'ish problem. The final step is elusive. No matter how far you would extend, that would not return to any specific hard point, because the specific instances are made.
Without a framing tool for connecting the two, a ready remedy is to frag. The problem is trivial, with frag -- through sharing (writing & reflecting on) intermediate memory locations. For example, a few for that NN73-2
The transition/activity frag for a5, could set the memory x1 to 1, and the rezolving for a1 would keep without decision, until memory x1 is 1. (The token from b8 is absorbable with a macro, as well as a feeding macro that would feed b1. Here, the fragging, is for regulating the two macros.
NN73 kind of environment function would do, too -- without any absorbing/feeding macro. With frozen@mid80, we represent any peripheral function individually. The frag for b8, the peripheral loc at the final point, would get rid of the token (that token is put there by a5 activity, along with setting the memory x1 as 1). The frag for b1, the other peripheral loc, is inserting a token, upon x1=1 (after that, a1 activity will reset x1 to 0). A remote-link for (wireless) looping. (cf. zapping).