Ready.
The input-"xor" macro-gate of copycat82, is essentially dead.
copycat82 admits that when two places get enabled simultaneously, it is a deadlock unless other components modify it (p.46) - but it never shows that "unless" in any example to resolve any deadlock. In ex-state, simply to add more tokens, will not do.
The input-"xor" corresponds to the Y-transition of E-nets, with no resolution. Although an E-net Y-transition, may also start a turn with no-resolution, that resolution is inherent to arrive right next - through the dynamic E-net-architecture, with the resolution procedures.
copycat82 uses input-"xor" in some wishful manner, to express "mutual exclusion." That obviously assumes being able to identify "deadlock-corners" ahead of time - whereas Petri nets identify deadlock with lack of tokens (i.e: not terminate properly).
copycat82 only crosses two inhibitor arcs, to stop each other. This is the most-primitive way, you could use an inhibitor arc. Although it is quite easy to use inhibitor arcs to express ideas, to use the input-"xor" may feel quite blunted. It limits the applicability of inhibitor-arcs to only explicitly-known deadlock corners - a bit similar to "assert" in C, which stops the execution. But here, the side-effects may go unnoticed.
A subnet with an "input-xor" anywhere in it, is, potentially, not proper, i.e: when/if a deadlock occurs, it changes the subnet-response.
If two tokens may ever arrive simultaneously, "xor" is unproper.
If two tokens may never arrive simultaneously, "xor" is only equivalent to a place/location with two inbound arcs (and also, to the other dataless copies of Y-transition, the "another-inclusive-or" and "priority").
Therefore, in a verified and reduced subnet, input-"xor" is never needed.
That is contagious, too. Even when an example, by itself, may not deadlock, in its two or three levels of nestedness, it may still crush, when in a circuit (e.g: in a loop).
If a deadlock-potential still lurks within that subnet, that means the attempt to reduce it, is only catastrophical. Although most, if not all, examples of copycat82 with input-"xor" may be deadlocked in some container-net circuit configuration, copycat82 still insists to claim to verify the subnets separately (instead of any necessary macro-expansion phase). It is russian-roulette, to trust such a subnet (as if equivalent), at all.
SARA CFA verifies the full-net together (except any valid reductions), but copycat82 assumes separate-verifiability. e.g: How was that "monitor" example of copycat82 (p.72) verified, if at all?
Most of the examples of copycat82, do get deadlocked - because both places may really get enabled, together. If copycat82 were ever to attempt to verify those sloppy examples, they would not probably be published with such obvious problems.
copycat82 uses a pair of mutual inhibitor-arcs, to invoke a deadlock (which also commits to Turing equivalence). Why need that macro? If ever a need were to occur, a net-modeler could trivially cross two inhibitor-arcs to invoke such a deadlock. This is easier to remember than the name input-"xor" - which only means, in fact, a deadlock.
Although copycat82 commits a lot of bad (deadlockful) examples, it never provides an example of a facility to resolve any deadlock, and/or to suggest why such an abusable macro-gate was ever needed/wanted - all of those examples being awful examples.