Ready.
copycat82, page 44, contains only the "Fig.3.3. The external view of a software component." It corresponds to the "Fig.3" of copycat83 (on its page 737).
The shape has three separate input paths, and three separate output paths - including a loop around itself. Such separately-standing arcs may activate a subnet, even when the other places do not have any tokens. How is that subnet, supposed to be verified (i.e: with what specified input/output token-flow scenarios)? How is that supposed to be assumed as a Petri net transition, when it is (imitative of VD78), "reduced after verified," to stand in a (container) Petri net?
Such a macro/"component" must be expanded, before a Petri net verifier is able to understand it. This was suggested by NN73, for all macros, but copycat82 does not discuss anything about such a need. This is especially problematic because, copycat82 does assume that subnets/"component"s would be verified separately. But when? To what extent, with what algorithm, and/or with what rules, must such a vague macro/"component" be expanded? That is not a problem for NN73, because they expand everything, and have a single full net. No separately-verifying. This fits well to the deterministic-simulations NN73 prefers. The separately-verified subnets are VD78 preference. As such, we find that, copycat82 is torn apart between the NN73 representation, and the VD78 methodology.
Such partial-firing is a usual pattern with the copycat82's example-figures. A constant source of vagueness - if not absurdity, as concerns being Petri net verifiable.
The letters Pi,Qi,Fi,Gi, all four of them, correspond to the Da80 formal letters, in Da80 section IV.E. (page 640-641).
The "Fi" is the resolution-procedure. i.e: It sets the preference of the token-flow paths.
The "Gi" is the transition-procedure. i.e: It modifies the variables/data, but not the token-flow.
It is not clear, why copycat82 has preferred the same letters for the same functionalities. It has a name "final states" for F (which corresponds to Fi), but "Gi" is altogether irrelevant. (Keep in mind that, copycat82/83 never cites Da80.)
The letter "Di" in copycat82 is not anything new, either. It is "data" and corresponds to the token-attributes, and the environmental-variables of E-nets, that Da80 is especially interested.
It is the "Ti" that presents a vagueness. Presumably, it is inspired by the next section of Da80, the section "V. Programming Languages," and its conclusion (both on page 641) where Da80 refers to hybrid-approach to Petri nets modeling.
The vagueness is about, copycat82's unability to notice that when Da80 discusses these, he must be already referring to the Fi and Gi. In other words, the procedures of E-nets are themselves the hybrid-approach. If you add anything further, you must provide some further authority to arbitrate between the dueling masters. i.e: whether the Fi-and-Gi, or any possible restrictions expressible by Ti would manage the token-flow.
This is left especially vague, because copycat82, although mentions Ti, and points at the Guttag's tutorial paper, itself never presents any type studies - within the Petri nets context. As a result, copycat82 does not appear to have thought anything about it - except an urge to look "different" from Da80. The "Ti" is only a redundant appendage, supposedly "yet another programming language, working on its own" - but without any worked-out examples within copycat82/83, to suggest any difference.