copycat82, cites JSP (on p.99), about structure of a program. Should we interpret the meaningless output macro "sequential-enable," and also the (unimplemented) "superscript" (i.e: repetition) operators, as an attempt to imitate JSP primitives?
If the "sequential enable" output macro was meant to show parallelism, at the exit of a node, it is a very awkward suggestion. The "p1 // p2" is equivalent to "(p1;p2) xor (p2;p1)" The "p1 // p2// p3" needs six such xor'ed terms to represent parallelism. And so on.
An alternative guess, about that "sequential-enable" macro, along with the (unimplemented) "superscript" (i.e: repetition) operators, may be an attempt to imitate the JSP primitives.
But that is more fit to E-nets, whereas the problematic copycat82 would be left with its false-assumptions about blocked-waits - where there may be none. i.e: E-nets (or, SARA) may readily implement JSP, but copycat82 cannot. As such, copycat82 is left in a similar position, as with most fans of Michael Jackson, the singer (not the software engineer). Such fans watch Michael Jackson, but cannot do the same.
Even if the E-net policy of blocked-wait were imitated in a (new, modified Petri net) verifier, the existence of internal places, within input-macro implementations, would make it useless. i.e: Even if the next node is busy, yet, the places in front of it, may contain no tokens. (It depends on whether there is "and"-or-none versus or/xor/priority/++. The latter contain internal places, and would not block the previous node, even when busy.)