BizTalk 2013R2: Why does my orchestration initialise after being terminated according to the Orchestration Debugger?

I am currently looking at diagnosing some reoccurring issues within a BizTalk environment and currently that is the issue of zombie messages. I am aware of the conditions that create these errors and whilst diagnosing the orchestration and making use of the Orchestration Debugger, I see that when a message has hit a terminate shape, it is followed by an initialisation.

The general structure of the orchestration is as follows:

The first scope is a long-running transaction and within the loop after that scope, there is a listen shape that waits for a message for 10 seconds. If a message comes in time, it enters another long-running transaction. It's like a singleton in a way? Both scopes share the same logical receive port and are correlated, only odd part is how the first scope is repeated within the loop that's inside the listen shape. (Orchestration is part of a behemoth of an application that wasn't written by myself.)

Would this initialisation after a termination (what actually causes this to happen?) cause zombies, if so is the structure of the orchestration and the transactions a cause of this? Or am I looking in the wrong place?.

Let me know if there's any extra information that can help!

In the Orchestration debugger it will show when something start and also when it ends with slightly different icons. So what you are seeing is the end of the Orchestration.

No, that will not cause zombies. Zombies occur after it ends the logical receive location that listens for something (and it is tearing down the instance subscription) and another message arrives that matched that subscription before the Orchestration has fully ended.