The short answer is: The Use Operator function is does not properly when the maximum capacity of the processor is larger than 1. This is also stated in the first warning box in the documentation.
This situation happens because when an item enters the processor and it currently has enough operators 'utilizing' it, it will not call new operators for that item. When the item that originally called the operator finishes processing, the operator is released and becomes idle. Any items that entered the processor in the meantime will keep processing. When a new item now enters the processor it will call the operator again. However, the next time any item finishes, the code that releases the operator will be executed, but possibly with the wrong item reference. The wrong reference causes the operator to stay utilized, but the processor thinks that it was released and will call the operator again for the next item that enters. Because the operator is still busy, this leads to the locking state you mention.
As a workaround, you can use the Task Sequence Example option for the operator reference. This by default implements the same logic as the default behaviour. In the attached model I edited it to prevent the processor from locking and to keep the operator state synced with the processor's. It works by creating a new task sequence right away when the operator is released and there are still other items on the processor.
workaround-fm.fsm
