copycat82 commits plagiarism, along with ignorance. The on-going self-contradictions, the utterly-schizoid nature, were obvious (also) with the macro-gate mess of copycat82. This page points out the ignorance of the "dataful" attempts of copycat82. Other pages point out the contagiousness, etc.
Even the versatile strategy of E-nets is more standardized. E-net transitions are well-defined, valid logic elements. An E-net, even without data, is verifiable for many aspects, as it preserves, for example, the rule that, for each firing
These rules are true for E-nets, Petri nets, and even for SARA nodes (except its multiple-possible arcs from an "inclusive-OR" but this is again a single-token per arc). The problematic exception is copycat82, which violates each of them.
Furthermore, an E-net input may never deadlock - unless the modeler lets it with data-preferences.
With E-nets, a (net-visible) deadlock may only occur if resolution is altogether omitted (explicitly, to invoke deadlock). With copycat82, "xor" corresponds to a Y-transition without any resolution.
Deadlock may also exist within procedures, although this is not about the (visible) net. It is very probably, a bad idea to keep critical variables (semaphore, lock-for-exclusion, monitor, etc.) only as data - especially if data may be ignored by the interpreter. e.g: In the "sample application" of copycat82 (on page 150), a semaphore is only a data-variable, and it is not represented in the Petri net, at all.
The only type of analysis copycat82 suggests, corresponds to the level-1 of VD78. i.e: The data, and program-fragments are to be ignored, at the end, although there is a possibility of zero-to-infinite tokens being released out, per any firing. This is certainly not the case with VD78 subnets.
copycat82 is not probably, about a deterministic simulation, either, although it presents the model in those terms, imitative of E-nets. For example, how would you decide, in a simulation, when to release the (next) token from a transition/subnet? Without any time-management, that is undefined (N/A).
i.e: It is not know when the token(s) will be released, but copycat82 also says that it/they cannot wait at the input-side. i.e: As soon as enabled, (all of) the enabled transition(s), must start (altogether). If this modeler-constraint is not to be neglected, that needs the (non-deterministic) verifier to enforce some non-Petri-net timing-requirements, too.