Ready.
Not proper. It is supposed to be a prioritized-firing operator, but once the higher-priority operator fires, the priority is lost (probably, forever). The next time, after a high-priority pass, there is no priority. In fact, as long as the lesser-priority path does not reach the same total of received tokens, no priority will ever be considered again.
That input-gate macro "priority" fluctuates. It is an expensive macro, too. It uses an inhibitor-arc, and also an extra/internal location/place.
Presumably, that "priority" was supposed to correspond to the SARA/UCLA logic-operator priority ('>'), or equivalently, to the Y-transition of E-nets, with a latched priority.
For example, if p1 is placed five tokens over the course of execution, p2 may have upto 4 passes, with full priority. Guaranteed. Furthermore, possibly, p2 may even have infinite full-priority firings (but not guaranteed to be) with equal priority because at times when p1 is not enabled, the firings involving p2 need not count for any priority-tokens. There is an alternate, altogether free route when p1 carries no tokens.
As a result, unlike what the UnPhD claims on p.47, the given macro is not "not nondeterministic" when both are enabled. It is nondeterministic in a very strange way.