One of my main concerns with our current design is the requirement for an alert to be triggered if no message of a given type is received before some given deadline (with the deadline being message-instance specific). This is difficult to accomplish on a message-event basis, as orchestration instances are instantiated by the arrival of a message. An instance cannot be aware of the non-existance of a message before it arrives, as it doesn't exist itself! (I'm sure something similar appeared as a plotline in The Hitchhiker's Guide to the Galaxy.)
This means that the orchestration instance, that would ordinarily activate upon receipt of a message, must exist already, before the message arrives. This is achieved by seeding an orchestration instance with a "message-expected" message that includes the deadline date, and for it to then listen for the expected message (even worse - it might actually have to poll for the message itself).
This seems completely counter-intuitive to the message-driven architecture that BTS espouses; an added complication is that once the instance is running, the deadline to which it is bound is fixed - you can't go in and tweak it, unless the orchestration is designed in such a way that it can receive (a la "sequential uniform convoy") further updates to its own deadline, by which time the orchestration is so complex that it would have been easier to shift the scheduling to a separate external application. This is particularly relevant in the current situation as the deadline might be 4 months from the time of the activation message, giving more than enough time for real-world events to require a change in the schedule.
So, we're now in a situation where BizTalk itself is managing the receipt of messages - it has to find out what messages are expected, create a new orchestration instance to listen for each one, and raise an alert if they don't arrive on time.
Et voila. Like some great illusion, we've managed to turn BizTalk inside-out, and make it the application.