Ready.
copycat82 publishes the macro-gate the so-called input-"another inclusive-or, ++" (on p.129), with an absurd "lock place". No use, at all. It does not change anything about token-flow, and it may not postpone anything. With Petri net instantaneous transitions, its net effect is exactly equivalent to a(n unbounded) place.
It is most probably photocopied (or, such) from VD78 Fig.4, where a similar pattern exists, but VD78 refers to subnets, i.e: NOT to instantaneous transitions. That is reasonable in VD78. It is irrelevant in copycat82, within a (data-less) macro-gate - where no internal-procedure is associatable, at all. It is absurd in copycat82.
And even if it were an error of VD78, the case would only mean to be a (blind) duplication of an error, by copycat82, (and again, by copycat83).
The point is that, VD78 lets expand any transition as a subnet, without any special shape difference to distinguish primitive versus non-primitive transitions. In a VD78 net, therefore, a lock-place is for (non-zero time) subnets, to avoid any time-overlap.
The copycat82 subnets are drawn as rectangles, in which the text of the resolution and/or transition-procedure is written. A primitive transition is only found, when implementing those trivial entrance/exit macros, where no program-fragment is relevant, at all.
The plagiarism of copycat82 messes in between, VD78 vs. NN73 (E-nets).
Although copycat82 echoes the concept of "design error," as VD78 had already pointed out, the macro-gate input-"++" of copycat82, is bound to commit such errors, unless we assume a wait-blocked policy, similar to E-nets.
If it were with that policy, "++" would be equivalent to a(n E-net) Y-transition, with random-priority, and without any transition procedures. Otherwise, whenever both of the input places hold a token, we would have to dump the model as a "design error" because this is the very definition of "++-in" i.e: It has two inputs, that will enable/fire, one after another (which leads to the possibility of an unsafe location, at the location that follows the "++." e.g: At the entrance of the "monitor" example (p.72) of copycat82. If two tokens arrive at "C1," the entry-place within the C1-subnet, must be able to pick the first, before the second arrives. With a non-deterministic Petri net verifier, the tokens surely bump at each other. No such "immediate-removal" or any "wait-if-blocked" policies with Petri nets. ).
In fact, as one of its obvious E-net'isms, copycat82 states an assumption/rule, for a subnet to "start execution as soon as a selected set of input control state variables is, enabled." and removes any tokens at the entrance, "immediately." This needs those input/output macros not to take any time, at all. Let alone, any time to even the ordinary transitions within those macros, when they fire.
That means, copycat82 assumes two other systems in two cases, although neither one is an ordinary Petri net, at all. Next, they clash with each other, too!
The confusion might have been that, copycat82 has falsely assumed that the photocopied VD78 lock-place would provide the implicit lock-place of a Y-transition, although the lock-place of a Y-transition is not only at the start-time. A Y-transition excludes the alternatives. Alternatives cannot exist together. In fact, VD78 Fig.4 is capable of alternatives-exclusion, but the way copycat82 has confined it to only the entrance, instead of start-to-finish, is absurd, it loses the sense of a lock-place. It does not exclude the "alternatives," as such alternatives may start before the previous ones finish their jobs.
Our inference is especially supported, because the macros that correspond to the Y-transition must have that full-exclusion, for the "sequential-enable-output" macro to make sense. Otherwise, it is another senseless macro, which tells about "sequence" although it has little, or no meaning, and it would be especially unmanageable with three or more output places. These all appear to be, an attempt to imitate the JSP (Jackson Sructured Programming) primitives, but without that full-exclusion of Y-transition (and X-transition, too), such a JSP'ness is not possible. That's where copycat82 loses. The moment it is not exactly the E-nets, the other parts of it start to malfunction.
The input macro "++" is a wasteful, and/or erroneous implementation. - with a useless lock-place. That is about the kindergarten-grade plagiarism of copycat82.
An "interlock" (lock-place) is useless there, because:
Unless we would call it "only verbose," it is an ignorance about the word "instantaneous." Pe77 refers to ordinary Petri net transition to be usually accepted as instantaneous. Also, the definition on p.26, of copycat82 does assume a (primitive) transition instantaneous. When taken such, the lock-place is useless. It only increases the number of states. With or without it, the two transitions may not fire at the same time.
As such, it is just another trivial Petri net case (two transitions pointing to a single, unbounded, place) given a name to memorize. You do not need any connecting operators for it. It is the default case, anyway. It is only transitions that output to a(n unbounded) place (implicitly a merge-place, a queue, etc.), because with the basic Petri net behavior, the following transition need not fire as soon as it is enabled. Hence, whether or not tokens are placed in p1 or p2, and in whatever amount, they can be unbounded/queued. Although UnPhD believes "Externally, a component starts execution as soon as ... enabled," nothing with a hierarchy built of basic Petri nets, can guarantee that. (Claiming that is more like being E-nets which have explicit functions for specifying the transition delay time, possibly zero-wait. Not for Petri nets.
As it is, the output location/place could correspond to a "[FIFO] queue-place" (with no priority), p.722 of NN73, as it would be an overloaded (unsafe) place, which is, implicitly and trivially, a queue, but 1-boundedness does not let that.
In VD78, transitions are possibly subnets that take time. Although copycat82 draws subnets with rectangles, as opposedto thin lines that represent transitions, it duplicates the VD78 shape, with a lock-place. The shape, copycat82 draws subnets, is rectangles, not thin lines, and whatever the shape, an "interlock" is useless there.
The single other context, where a subnet is represented with a thin-line, on page 131, is very noticeable as imitative of VD78, too, as it is a point very anthagonistic to many/most examples in copycat82. It is with a bottleneck, that lets a verifier work, as with the VD78 strategy, whereas in many/most examples of copycat82, the macros have multiple separate paths, un-coordinated with each other, at entrance, and/or exit, and even at intermediate positions, as "socket-calls." As such, that figure on p.131 is patently not copycat82 itself, any way. It fits VD78 - although copycat82 does not even refer to it as a source.
The observation of "timed-transitions" as copycat82/83 admits, possibly occurred later, and not as a "design-preference." Why bother first reverse the Petri nets by stating "as soon as"ness, then undo that with such extras? (And copycat82 does not tell about a time-potponement, in words, about that macro-gate "input-++.") That does appear to be just one of the many many faults of copycat82 - a lot of which do not even have such a (vague), "possible second explanations."
In summary, such a lock-place is either absurd (useless), or it assumes itself as if it were E-nets, with a blocket-wait policy. The net effect, with Petri nets, is that it is only an input place, being pointed by two inbound transitions. If that could change the meaning, in the examples, I may interpret with both assumptions - to point out whether the example assumes E-nets, or Petri nets, if workable, at all.