Ready.
The so-called "inclusive-OR" input-macro of copycat82, is not proper. The name "(inclusive) OR" would suggest, "either, or both." But the implementation is such that, it needs both entrances to receive tokens, to be able to restore itself. Otherwise, it will be blocked, in any later passes, through it.
The specified behavior is that it is supposed to be run only once whether p1 or p2 or both are enabled (holding tokens, that is). If p1 enabled the component, p2 cannot restart it. The second/matched token is only absorbed. That specification (p.46) does not suggest the blocked-unless-strictly-turn-taker behavior of the implemetation on p.129.
For example, if p1 is enabled, that macro-gate sends out a token. But next, that macro-gate needs a token also in p2 (to do nothing but to restore itself to its original state). In other words, if the circuit "enables" the operator several times by using the same place (e.g: p1), the tokens will only pile up there - until the other place does the do-nothing transitions to match each firing - unless the verifier dumps it away because it is not 1-bounded.
Is it Soviet (or, War-time) Petri nets, to ration with that "inclusive-or?" i.e: You cannot take a second bite, until the others eat as much. What "or" logic is that? One may still find some meaning to use it in an example, but that is not what copycat82 does. That Un-Credible Ph.D. lacks any proper example with it.
As a point to notice: In the "monitor" example (p.72) of copycat82, one of the absurd problems where "xor" is used, would not exist if that were "or." It is still very idiosyncratic, though.
For the readers, if interested, I could suggest two other implementations, for a real "inclusive-or" macro. e.g: To resemble/imitate SARA/UCLA graphs inclusive-or, as with SARA CFA. Even if copycat82 were any success to implement inclusive-or this way, that would still be no big feat to reward a Ph.D. title, any way, though: