Instead of using the process flow to influence the 3D logic, it might be easier to have it control the item flow directly. (It would be tricky to hit the right timings to change the allowed types of the pull requirement).
In the attached model the rack pushes all items with 'Lavoro < 10' onto a list instead of sending them through a-connections.

In the process flow, two tokens are created for queue, one in the upper flow and one in the lower.

The upper flow pulls unprocessed items from the list and has the ASRS move them into the respective queue the token belongs to. The tokens then wait until that item has left the queue again, so there can never be more than one non-processed item in the queue at a time.

The items are send to the processors by the 3D-logic. But like the rack, the processors also push the items back onto the list when they finish processing. The tokens of the lower part of the process flow then pull these processed items. To demonstrate a different approach, the transport is not controlled through the process flow there. Instead, the process flow tells the processor to release the item through the connections corresponding to the token's queue.
For this, an array label that contains all connected processors is added to the token. The correct connection can then be determined by the position of the processor in that array.

spaggiari_fm.fsm
Finally I would like to add: The simplest solution here would likely be to just have two queues at each position instead of one; one for the unprocessed items going in and one for the processed items coming back.