In this new answer I will try to explain based on the “Stateless” library mentioned in OP.

Draft.

More information will be added after I get my hands on Stateless.

In any sense, extension to Stateless is required. Fortunately this is highly doable because Stateless is highly extensible using its partial class approach.

A simple description is that:

• One business process = a bunch of activities
• Each activity requires one StateMachine object. See link to library.
  • This is necessary because in some circumstances, each activity can have their own state transitions, as explained in “parallel split workflow” by OP.
• Some activities are non-trivial (requires an extension to the Stateless library object), which might be implemented in several ways.
  • One kind of non-trivial activity is to embed (or nest, or delegate to) another business process.
• The business process must mediate the state transition rules across all activities, and this requires an extension to the library as well.)

The typical states in a Activity object:

• NotConfigured
  • Only exists programmatically. Compare this to a non-fully-initialized object.
  • An activity may require some parameters (e.g. for an Email activity, a email address needs to be configured) before this activity can be triggered.
• NotNeeded
  • Indicates that, in its current configuration, this activity does not need to be executed in order for the containing business process to be “completed”.
  • This state is reversible. It can be “reactivated” upon receiving a trigger from another activity.
  • Example: citizen needs to fill out a SSN. Non-citizen needs to fill out either ITIN or W8-BEN. In either case, one of the activity is not needed. However, if the employee makes a mistake in the option, this mistake should be correctable by clicking a checkbox. This has the effect of deactivating the activity no longer needed, and reactivating the activity now needed.
• Succeeded
  • This state is final (irreversible). Once set into Succeeded, it cannot be set to any other state.
• Waiting, with the following substates:
  • WaitingOnPreconditions
  • WaitingOnInternalTrigger
  • WaitingOnBusinessProcess
  • WaitingOnExternalTrigger
• Faulted, with the following substates:
  • TimedOut,
  • InternalError
    • Contains a stack trace (if it is a programmatic error)
    • Captures a snapshot of the state machines of each activity inside the business process (if it is caused by some invalid state transition requests or mis-configuration of the business process)
  • ExternalError
• Canceled, with the following substates:
  • CanceledByBusinessProcess (the containing business process is canceled)
  • CanceledByInternalInvoke (this activity is “nested”, and the parent activity requested this to cancel.)
  • CanceledByUser (by someone with a user ID)

Sometimes, a single activity in human sense must be broken down into multiple activities in software implementation. This will have implications on the design of the Graphical User Interface (GUI). In short – GUI can get very complicated.

Example: a business process modeler will regard “wait for email approval” as one activity. Internally, it is broken down into these activities:

• Format email template and send email with email server.
• Choice: (both are waiting, but only the first one will become Succeeded, as the other will be promptly set to NotNeeded.)
  • Wait for approval email reply.
  • Wait for disapproval email reply.
• An exception catcher for timeout.
• An exception catcher for anything but timeout (e.g. problem with sending the email, or parsing of the approval/disapproval response)

Displaying all these details on the GUI will make it difficult for the user. Instead, the user should only see options that the user intends to configure.

Almost all interactions (dependencies) between activities are modeled as the “Waiting” state.

WaitingOnPreconditions is the simplest type. Simply speaking, it can wait on final states but not states that flip-flop. Usually, it waits for a set of activities to all transition into the “Succeeded” state. (On the opposite side, it can also wait on “any activity that transitions into the “Faulted” state – this makes it an exception catcher.)

Because the inputs to WaitingOnPreconditions are not allowed to flip-flop, the outcome of WaitingOnPreconditions will also not flip-flop. This is the essential distinction between WaitingOnPreconditions and WaitingOnInternalTrigger, described below.

WaitingOnInternalTrigger is more dynamic than WaitingOnPreconditions. It waits on some observable variables on the business process object to change to a certain value, or some other activities to change their states.

Once entered this state, the activity’s StateMachine stays there, unless requested (programmatically) to re-check. The check might be performed with a predicate, Func<bool>, or lambda expression.

The business process object contains some variables that have INotifyPropertyChanged interface. When that event is raised (that is, when the variable value is updated), activities that are in this state (WaitingOnInternalTrigger) will be re-checked.

To avoid indeterminacy or deadlock, the re-check is only allowed to use variables which it can observe. Otherwise, nobody will notify the activity of the relevant changes, and the activity will thus stuck in this state forever.

WaitingOnBusinessProcess is used when an activity embeds another business process. That other business process runs somewhat independently (in software sense), and the current activity will wait for it to finish, cancel, or fault.

WaitingOnBusinessProcess is re-checked whenever the business process it is waiting on has changed state.

WaitingOnExternalTrigger is a mechanism to block the activity until it is unblocked by some other means. For example, it might be waiting on some user interaction, or an approval email. Unblocking is done programmatically – not by another activity or business process.

Every WaitingOnExternalTrigger must have an associated exception catcher (mentioned earlier). This is because all external processes are presumably unreliable, e.g. the employee responsible for this business process might be fired on the spot, (or the email server was struck by a disaster) and thus unable to continue the process.

Other references (not used in my answer)

• Homepage of Wil van der Aalst, mentioned as the primary reference for OP’s design.
• Business Process Model and Notation (BPMN)

Disclaimer: my employer makes BPMN software. However, I do not work in the BPMN product team, and my answer is not representative of my employer’s viewpoint. I do not have any privileged knowledge of the BPMN product.