What is the behaviour when executing this test? And what did you expect instead?

What is the behaviour when executing this test

back1:

1. take token from b, set to a
2. take token from c, set to b

Result: tokens in a and b.

back2:

1. take token from c, set to b (but the marking in the current implementation can only contain one token per place)
2. take token from b, set to a

Result: token in a.

The implementation is similar to Petri Nets, but with the difference that if another token moved to place, it will be ignored. That is the problem.
If fix this, it will change the behaviour of current workflows. It is also impossible to leave it as is, because the graph cannot depend on the order of declarations of its structure (see example, when visualizing there is no difference betweenback1 and back2.) Probably the only reasonable way is to validate and prohibit such transitions.

And what did you expect instead

Like Petri Nets:

back1:

1. take token from b, set to a: a(1), b(0), c(1)
2. take token from c, set to b: a(1), b(1), c(0)

Result: tokens in a(1) and b(1).

back2:

1. take token from c, set to b: a(0), b(2), c(0)
2. take token from b, set to a: a(1), b(1), c(0)

Result: tokens in a(1) and b(1).

Possible safe solution (need validate):

Change Marking:

    public function mark(string $place): void
    {
        $this->places[$place] = ($this->places[$place] ?? 0) + 1;
    }

    public function unmark(string $place): void
    {
        $this->places[$place] = ($this->places[$place] ?? 0) - 1;

        if ($this->places[$place] == 0) {
            unset($this->places[$place]);
        }
    }

    public function toState(): void
    {
        foreach ($this->places as &$place) {
            $place = 1;
        }
    }

Add new argument toWorkflow:

    bool $tokenAsState = true

In apply, after do all approved transitions:

if ($this->tokenAsState) {
    $marking->toState();
}

This allows:

• Safe parallel transitions (fix this issue) with saving current behaviour.
• Work like Petri Net when tokenAsState is false.

Hm... This has indeed been the case since forever. Interesting.

Since we are building a list of "approved transitions" and then apply them one by one (and not as a unit) we will have this issue.

With your proposed solution, do you see how/if that would effect listeners to Transition('back2', 'c', 'b')?

Like Petri Nets (#53179 (comment)), but only in apply when tokenAsState=true

listeners must not be affected

Behaviour should change when we set tokenAsState=false.

For example we can use createWorkflowWithSameNameTransition (https://github.com/symfony/symfony/blob/7.0/src/Symfony/Component/Workflow/Tests/WorkflowBuilderTrait.php#L90):

//   +------------------------------------------------------------+
//   |                                                            |
//   |                                                            |
//   |         +----------------------------------------+         |
//   v         |                                        v         |
// +---+     +---------+     +---+     +--------+     +---+     +------+
// | a | --> | a_to_bc | --> | b | --> | b_to_c | --> | c | --> | to_a | -+
// +---+     +---------+     +---+     +--------+     +---+     +------+  |
//   ^                         |                                  ^       |
//   |                         +----------------------------------+       |
//   |                                                                    |
//   |                                                                    |
//   +--------------------------------------------------------------------+

// a: 1
// b: 0
// c: 0
$workflow->getMarking();

// a: 0
// b: 1
// c: 1
$workflow->apply('a_to_bc');

//   a: 1
//   b: 0
//   c: 1
// or
//   a: 1
//   b: 1
//   c: 0
//
//.a: 2
// b: 0
//.c: 0
$workflow->apply('to_a');

Alternatively - we can simply add a check for places in transitions with the same names in the WorkflowValidator :)

It would not be a bug fix but a feature, since this was always intended this way, cf #22521 (comment).
And a very old proposal #20508.

I would be happy to have such feature though, it has been on my todo list for a long time :).

Hello, Sorry for the delay. I confirm this is something not expected... It's a current limitation of the workflow component as @HeahDude told previously.

I would be happy to have such feature though, it has been on my todo list for a long time :).

Me too. So here we go : #53865

The PR has been reverted. I'll send another one against 7.1