Sorry. When it is not perfectly clear what the issue is to start with, lacking the proper context makes it is very difficult to follow a long discussion, which often jumps around to places not relevant to the problem. It's OK to leave the discussion, as long as it's stated concisely what the problem is. By that I mean 1) what you are doing, 2) what actually happened, and 3) what you expected to happen. You did a good job summarizing your issue here, even if you didn't number the parts. 😉
When trying to help someone, very often having the person guess at where the bug is or provide solutions is detrimental and makes it difficult to even determine what is problem they are experiencing, especially in a complex scenario. Stating clearly exactly what you are doing, without speculation, provides the proper context. Then, separately, explaining what happened and what you expected allows us to see if your expectations were reasonable and if the behavior you are seeing is correct based on what we designed it to do. After that, feel free to (separately) discuss where you think the problem might be and any possible solutions.
Posting a project or example can help, but this is very time consuming to research. Often the examples have not been paired down to show only the problem and are very complex, so don't serve as a good way to reproduce the issue. We don't want to dig through a whole application. Often we get examples with no explanation, so we dig around a bit, find out we can't guess what is going on, and have to ask for more information. If I don't understand what the problem even is before opening the project, the project is probably not going to make much sense since I don't know what I'm looking for.
That said, I assume Pharan did try your project and then decided to write a simpler test, as he posted in your thread. I'll let him respond about it there.