Ready.
copycat82 commits to vagueness, with its ill-structured subnets, although it still expects them to be separately-verifiable, as if that were VD78. Such vague-macros cannot be assumed as equivalent to VD78 well-formed subnets (or, Petri net non-primitive transitions). A net is not verifiable, if it contains such copycat82-subnets in it. An insistence to verify such a vagueness, would only lead to maximal complexity.
As long as copycat82 cannot suggest any advantages about such vague chops, most of us would rather prefer, a few Walt Disney cartoons, instead of copycat82, to annotate Petri nets, or SARA. e.g: a Donald Duck, to comment about a net, for example, with stickers that have balloons to write in. This is, at least, neutral. By contrast, with copycat82, you would start with structural faultiness - the gotchas.
NN73 (Macro E-nets), was already with macro-nets, for a more intuitive modeler. But in NN73, the problem is avoided, by an expansion of any macro-net in it, when it is time to interpret/verify the net.
NN73 was published 9-10 years earlier than copycat82/83, although copycat82 is a subset of NN73. NN73 introduces macro-nets to represent nets with improved intuitive appeal, without a need to rewrite the E-net interpreter - every time a new valuable pattern is thought of. Macro-nets are very easy, and versatile.
SARA SL restricted that macro-net versatility, with a software methodology, and its system-software to support it.
copycat82 is a subset of SARA, too. In SARA, the control-nodes vs. SARA SL modules. are different, although copycat82 does ignore that. Such ignorance, along with the plagiarism of copycat82, make copycat82 worthless. It is worse than trivial.
The examples of copycat82, so often, cannot even be represented, with the formal structure it copies from E-nets (esp. Da80). This is not a limitation of E-nets. It is about the vagueness of copycat82 which collapses separate concepts, and it never provides any algorithms to sort them out, again. e.g: primitive-transitions vs. macro-nets. (Or, in SARA terms, control-nodes versus SARA SL modules.)
Needless to say, when its examples turn out to be so awful, the chapter where copycat82 attempts to "tell about how such examples could be prepared" borders at the insane. It is not "design." It is only ignorantly chopped-graphs, along with other garbage, which copycat82, even itself, does not paint correctly in its examples, and next, gets rid of them, when about to verify the net. It is also excessively faultfulllll.
N.B: This is Petri nets. Not sausage. When chopped as such, a lot of them turn out to exist as vaguely-chopped macros. Even its own examples, contain such impossibilities as "socket calls" (imitative of SARA) from within a subnet. That obviously, cannot be verified by a Petri net verifier. If no compatibility with Petri nets is to remain, the meaning is lost, as far as a Petri net verifier is concerned, and even English-sentences jotted on an envelope, would compare, to copycat82 "design method." Both would be equally senseless (i.e: without any formal meaning), as a representation - unless a human makes sense of the vagueness (a paradox, possibly, because vagueness is not sensible, in general, if ever), and converts it to some formalism that is verifiable.
The section 4, about design, is only about trivial halving, or joining. It is false, even at such a trivial task, and it is not worth mentioning, even if it were corrected. Nothing new there.
Only chops and glue, would not do. The chops lose information. e.g: if a chop is not proper, or if it is deadlock-prone, this information is lost, when it is assumed as if it were a properly abstracted subnet/transition.
It is pencil-and-paper, and also rote memorization-overload/abuse (especially when two macros interact, over many phases, as with "socket calls"). At the both extremes of unusability, at once. Mental simulation, as it is ... Data-name boxes do not contribute, on the paper, next to the procedure-text, but they do increase the tediousness, to draw them at every level, yet again. Not to mention the long-distance travels of those arcs, within the cluttered graphs, when the graphs contain a lot of useless elements.
Instead of being stuck with copycat82, it is probably easier to translate Pascal itself to Petri nets. No need to correct those faultfull and quirky (fault-prone) macro-mess of copycat82.