I agree, it looks awkward but this is what our business process is.
We are lucky actually to have this pattern twice in one orchestration:
1. loop in which we determine if all the required data available. if yes – go further, no – send request to user and wait answer or timeout. User response starts the check cycle again.
2. loop again where orchestration tries to send a message to ext. system and wait for a response or times out. If response then exit from orch. If timeout – weird business logic – we still wait answer from external system and in the same time command from user to retry or for the final timeout which is orch. exit.

I can imagine that there is possibility to decouple this orchestration and replace this non deterministic logic with series of pusher-subscriber chains but this orch is so complex and has so many variables/messages/operations/exception handlings aside from this weird pattern that I can’t figure it out….

13. A race condition or deadlock in library code is always a bug.

http://www.bluebytesoftware.com/blog/PermaLink,guid,f8404ab3-e3e6-4933-a5bc-b69348deedba.aspx

BizTalk is the library in this case and this problem should have been better addressed by MS.

A workaround for certain scenarios much like the one of Victor: disable the receive location by code in the orchestration, wait twice the cache interval (forgot why exactly) and asynchronously start orchestration that enables the RL.

Antoher workaround that I used for singleton: a service window around midnight for the RL, inside the delay branch of the listen shape you can check the time and if you are inside the service window (take a margin here + or – 1 or 2 minutes) you can more or less safely recycle. That solved the problem for me. I guess it is not bullet proof either but it worked for us.

Gregory