Ready.
copycat82 mentions two types of places in a net, but it is mentioned only in a step of the reachability-test (page 138). No such "two types" exist in the representation - or, at least, it is vague. The most probable explanation is that, it is about two (explicit) types of net places/locations in a single net. This page, instead, explores the other, the unlikely, alternative.
Within any macro-transition (non-primitive transition), there is a(n implicit) place, used as the token-holder busy-place, while the macro is busy. Is that the "second type" of place, which copycat82 mentions? But any such place, exactly follows the first type of place, the "control state variable," in front of the macro. If the internal (implicit) place can get unbounded, the previous place may always get unbounded, even before that - and, that means unsafe, too.
To repeat in context: (1) A wrong-statement in copycat82 may be an attempt to get rid of this, but a Petri net verifier would not make sense of it, any way. Specifically, copycat82 claims that "as soon as a component is enabled, the execution starts, and it removes the tokens immediately," but a Petri net verifier does not do that. To do that, it must know "two types" of places/transitions. Most concisely, that might be "zero-wait" vs. "non-zero-wait." That does suggest that, while copycat82 attempts to be similar to E-nets (or, to SARA), it forgets that Petri nets are different. i.e: Petri net transitions never need to fire, let alone "immediately" when enabled.
To repeat in context: (2) Yet other problems exist, with those input-macros, beyond "zero-wait"ness, (see, pages 129, 130, and 132). And it is about the plagiarism of copycat82, too, as it attempts to imitate E-nets (and/or, SARA [CFA]) about entry/exit through (macro) transitions/nodes.
With the (problematic) input-gate macro-implementations (on its pages 129, 130), the case would be that, the reachability-test lists the unsafe "control state variables" if-and-only-if, it is a single-arc, or there is an "and" of those multiple paths, or the "xor"/"or" macros were stuck. With single-"and" cases, a multiple-business case is not representable, with any "internal" place, because the macro-implementation for "and" does not contain such an extra place, and the single-arc is without any macros, any way. When we consider all such cases, it is a quite strange bag of unsimilar expectancies.
e.g: What necessitates a service to serve only a single customer, if it requires ("and") two conditions? Why does unsafety mean stucked-macro in some cases, ("or", "xor"), but no problem in others (single, "and")? i.e: There is no unique sense to interpret the case "unsafety at input variables."