Ready.
It is absolutely trivial to imitate SARA i/o logic with the macros of Macro E-nets (NN73), but copycat82 is worse than trivial, again.
In fact, except the inclusive-OR macros, the other SARA/UCLA control-logic already exist as the E-net primitives, any way. To imitate SARA with E-nets, to nest E-net expressions with parantheses (formally), we may simply list the (paranthesized) subexpressions, as the locations for the E-net primitive that refers to them. The Xn-transition is a ready example, as it corresponds to the "exclusive-or" output macro of SARA. e.g: An Xn that lists three locations, as the alternative paths, which may, in turn be other such SARA-style macros.
This is trivial, although it is not necessarily the preferred Macro E-net style. The E-net macros favor new abstractions. This is what provides their clarity. Nested-macros, to provide a single logic-gate may feel less than perfect, as it is spread around. That was obviously not the preference, when NN73 presented the macros (p.721), e.g: reflect on NN73 example of An,m, or the Fn (instead of "a and (b and c)"), etc.
The operator-signs of copycat82, stand between inbound arcs, imitative of SARA/UCLA i/o control logic. The operator names also (attempt to) imitate SARA/UCLA ("and," "inclusive-or," "exclusive-or," "priority").
As a result, the reader may wonder whether this is SARA CFA, as it replaces SARA i/o logic at the entrance/exit, with equivalent Petri nets, to make it verifiable by a Petri net verifier. This is what SARA CFA does, to transform the SARA/UCLA graphs to Petri nets, to verify a net with the Petri net reachability-test - after a reduction.
As such, a totally-SARA bias, would suggest that copycat82 exactly copies SARA CFA. But copycat82 lacks the extras (e.g: the reduction), and copycat82 commits a lot of mess at even such a trivial attempt to duplicate the input/output gate macros of the prior art.
The plagiarism of copycat82 is a multiple-sources cut-and-paste, in general, and it involves mutual conflicts, between the copied sources, as it is also the case here, with its plagiarism at the input, and its plagiarism at the output.
In place of the E-net resolution-location for a transition, copycat82 dumps the names of all the involved "data-items" (which supposedly entail their data-types, too). This is noticeable, in its Fig.3.7.(d) (on page 68), which directly corresponds to an E-net X-transition. Next, the placement of the operator-signs, between the in/out arcs, is imitative of SARA. It is the kindergarten-grade plagiarism of copycat82.
The "data-item" and the "data-type" are already what E-net resolution locations, pointed at, i.e: the data-dependency.But nobody would publish them, in such a way, probably, because copycat82 only draws in those figures, what E-nets already refer to, within the token-attributes, and through resolution location/procedure. There is only the cut-and-paste from the formal listings, to the graph, with its excessive clutter.
That does suggest the origin of those little data-boxes, placed everywhere around the graph, just where, in the E-nets case, stays the resolution location.
copycat82 similarities to the E-net representation is also noticeable (on its page page 68), where copycat82 paints the five shapes, the three parts (b,c,d) of which correspond to the three parts (again, b,c,d) of the E-net primitives (Fig.1, p.719) of NN73. (The a part is Y-tran, albeit it is verbose, with a vague ADT-name rectangle (see page 68) Especially, noticeable is the position of the "data-item," analogous to a resolution-location, as it points to an X-tran.
copycat82's so-called "input/output transfer specification" (gate) macros resemble the E-net primitives, and/or the SARA/UCLA control logic. If a primitive does not exist in E-nets, it is faulty and/or quirky (fault-prone) in copycat82. Period.
The plagiarism of copycat82 encompasses its input-gate, and its output-gate, too.