What does this module differentiate from https://drupal.org/project/maestro ?

Thanks for asking — fair question. We just added a dedicated page for exactly this: Compared to Maestro.

Short version: Maestro is a mature, task-template engine, especially strong for content-approval flows. Orchestra is a different engine — a token / Petri-net core — built to remove some structural limits once a workflow stops being a single, mostly-linear approval chain:

• Composable routing. Branching and joining are not special task types (If / And / Or); they are properties of any node — per-flow conditions plus the node's split and join policy. The named gateways (exclusive, parallel, inclusive) are just presets.
• Real concurrency with branch-local data. Variables can be token-scoped (visible only to a branch's lineage), and a join can merge one value per branch into a list — so a quorum ("two of three approve") is wait_all + merge + a count condition, no custom code.
• Multi-tenant from the first install. Every instance, token, variable and task is scoped to a tenant resolved per request.
• Distributed execution. The same client contract drives a workflow in-process or on a remote site over an OAuth HTTP API.
• Plugin-extensible everywhere. Task types, flow conditions, splits, joins, assignment and timeout actions are all attribute plugins.
• Standard, accessible authoring. BPMN.io plus an accessible form-based modeler.

To be fair, Maestro is more turn-key today for content approval: interactive tasks that open an entity form, a content-moderation bridge, and first-class notifications — all on our roadmap. If you want a proven content-approval workflow now, Maestro is a solid choice; if you need real concurrency, quorum, multi-tenancy or cross-site orchestration, that is where Orchestra is aimed.

The linked page covers each point with diagrams and examples. Happy to take follow-ups.

Thanks fishfree, glad it resonates! Let me set one thing straight so the comparison is accurate.

You are right that authoring is the visible difference from Maestro: Orchestra edits workflows through the Modeler API, with BPMN.io (a BPMN 2.0 toolkit) as one of its modelers, and it restricts the palette to the shapes the engine can actually execute. So the diagrams use standard BPMN notation, where Maestro ships its own bespoke canvas builder.

But I would not claim Orchestra is "standardized with BPMN 2.0 / ISO/IEC 19510:2013". That standard governs execution semantics and serialization conformance, and Orchestra is not a BPMN 2.0 engine:

• The runtime is a token / Petri-net core, with Orchestra's own node types (start, end, user, action) and gateways expressed as split and join plugins, not the BPMN element set or its execution rules.
• We borrow BPMN.io for authoring ergonomics, not for standard conformance: there is no BPMN XML interchange guarantee, and only an executable subset is modeled.

So the honest framing is: a standard BPMN.io authoring experience over a modern token-based engine, rather than a BPMN 2.0 conformant implementation. And because authoring is modeler-agnostic, you can skip the diagram entirely and build the same workflow in accessible Drupal forms (the Orchestra CM submodule).

A first alpha version will be released soon, we are almost feature complete.

https://project.pages.drupalcode.org/orchestra/maestro/