Ready.
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.)
It turns out again, that copycat82 is stuck with its plagiarism and with its worthless, worse than trivial attempts.