Thought I’d throw in some ideas here.
Perhaps you could explain a bit more about the business reason for maintaining two sagas for the same order? Think this will help us understand the use case a bit more.
I’m in the process of implementing a saga for long running orders where they can timeout if not actioned within a given time frame. Rightly or wrongly I’m not using the saga timeout but instead use a few extra services.
In my case I have a saga management service - this is responsible for maintaining the core order saga details ie create and update the saga. In my case I have one saga record per order.
When the order is created I fire off an event e.g. ManagedOrderCreated. This event is handled by a few other services, a service which materialises a view for the end user, but also a Managed Order Expiry service. This Managed Order Expiry service sole purpose is to monitor and action the expiry of a Managed Order. When a Managed Order expires it fires off a Managed Order Expired event which the main saga service listens to and finalises the saga.
When an order is updated a Managed Order Expiry Change Event is fired (if the date has changed) so the Managed Order Expiry service can update the expiry info.
By having this sort of setup it allows us to have another service listening to the different events and writing out a history (log book) of what has changed, which keeps the saga usage quite lite.
Obviously this is our use case and yours could be different, but thought I’d share that idea incase it helps.