question

This does appear to be a bug.

When the On Exit trigger fires on Processor2 in the red and blue areas, openinput() is executed (because the condition is true), and the processor's input ports are opened. However, flowitems start to enter the processor even before On Exit finishes executing. For Processor2 in the green area, items don't begin to enter the processor until after On Exit finishes. This is true even when you increase the processing time to give the second batch of items long enough to enter Queue2.

As @Felix Möhlmann mentioned, having only one item enter Processor2 in the red area is strange. It makes sense that 29 items enter in the blue area, since there is technically still one item in the processor during the On Exit trigger. I'm not sure what the difference is between the two.

Whatever the case, I'm guessing the general issue has something to do with the normal logic that controls input and output ports on Fixed Resources and Task Executers (https://docs.flexsim.com/en/22.0/ConnectingFlows/Ports/KeyConceptsPorts/KeyConceptsPorts.html#open). However, I haven't been able to dig into it enough to know if that is the case.

I will send a bug report to the developers to help sort it out. For now, you will just need to follow one of the workarounds that Felix mentioned in their comment.

The original answer was deleted where Felix had commented, so here is the content of that comment:

There might be some confusion here based on the title of the post? They are using the default trigger pick option "Close and Open Ports" which use closeinput(), openinput(), closeoutput() and openoutput(), which, while deprecated, are valid commands and do (to my knowledge) the same as using the property.

This seems like a timing issue/bug with things happening in the wrong order. Though the "red" case in which only a single item enters the processor seems particularly weird.

As a workaround you can shift the trigger that opens the output to the next downstream object: Opening when the 30th item has entered the queue, rather than when it is about to leave the processor.

Alternatively, send a message with a delay of 0s to the processor in its exit trigger and open the input in the On Message trigger. That way, all items will have left the processor before new ones can enter.