My fellow BizTalk MVP, Leonid Ganeline, asked if I would comment further on mechanisms to govern sequential flow in rules in MS BRE. He was picking up on some comments I made in my article comparing WF and MS BRE rule performance (see http://geekswithblogs.net/cyoung/archive/2007/08/12/114597.aspx#143628).
What I had in mind was the use of state transition patterns within rule sets. These can be used to layer a degree of sequential control over the set-based pattern matching approach taken by engines like MS BRE. The basic pattern is simplicity itself, and very common. What I generally do is assert an additional ‘context’ fact to the engine (typically some custom .NET object) in which I maintain a state specifier (e.g., a simple string property). I can then group rules together to match specific states, and use a low-priority rule in each group to change the state. The ‘sequential’ flow is then governed by the state transitions. Of course, any single group of rules that match the same state do not operate in a sequential fashion amongst themselves. However, you can always just have one main rule per state if you wish. Here is a very, very simple example of the kind of pattern I have in mind.

/*********************************************
* Group 1 – ‘Started’ state
********************************************/

Rule 1
IF
AND
Context.CurrentState == “started”
MyFactA.Property1 > 5
MyFactB.Property1 < MyFactA.Property
THEN
MyFactB.Property1 = MyFactA.Property1
assert MyFactB

Rule 2 (priority -1)
IF
Context.CurrentState == “started”
THEN
Context.CurrentState = “initialised”
assert Context

/*********************************************
* Group 2 – ‘Initialised ‘ state
********************************************/

Rule 3
IF
AND
Context.CurrentState == “initialised”
MyFactA.Property2 == “USA”
THEN
MyFactA.SetCountryCode(“01”)

Rule 4
IF
AND
Context.CurrentState == “initialised”
MyFactA.Property2 == “UK”
THEN
MyFactA.SetCountryCode(“44”)

Rule 5 (priority -1)
IF
Context.CurrentState == “initialised”
THEN
Context.CurrentState = “completed”
assert Context
assert MyFactA // convenient place to re-assert MyFactA
//to avoid loops if, for example,
// MyFactA.SetCountryCode() changes the
// state of MyFactA.

/*********************************************
* Group 3 – ‘Completed’ state
********************************************/

Rule 6
IF
AND
Context.CurrentState == ” completed “
THEN
MyFactA.Property1 = 0
MyFactB.Property1 = 0

/********************************************/

The low-priority ’state transition’ rules are rules 2 and 5. Group 2 contains two main rules, whereas the other groups have just one main rule.
Personally, I think MS BRL (and the Rules Composer) should provide a built-in abstraction for this design pattern – i.e., provide a way of grouping rules by state, and declaring how to transition to a new state when a group has completed its work. If this was supported, it would not be necessary to explicitly define an additional low-priority rule in each group.
This design pattern can be a little difficult to maintain in MS BRE currently because the rule composer displays rules in alphabetic order in the UI, regardless of the order in which you created them, and so you cannot see the groupings and state transitions. The answer to this, of course, is to adopt a rule naming convention which makes the pattern more explicit in the UI.
I used this design pattern recently when creating a rule set for applying Bayes Theorem. See http://geekswithblogs.net/cyoung/archive/2007/08/27/114988.aspx. The rule set was written for other rule engines (Jess and CLIPS), but uses exactly the same principle. I have ported the rule set to MS BRE, but just need to clear a potential commercial hurdle before publishing the code.