I'm not convinced with this tip + previous note.
There is too much to way about the marking store.
Chould we add a new chapter (in this page OC) instead?

This is wrong

No.. I would say this is very true. But maybe we can express it differently.

Workflows usually have a defined start and end. State machines usually keep running forever.

I still disagree. Why do you say a State Machine keep running? I had many state machine that have a start and a end too

both workflow or state machine are either cyclic or straight forward, no?
for me the only difference is the state representation, single or multiple
but not transitions process

I had many state machine that have a start and a end too

That does not make you correct. =)

A mathematician would disagree with you.

But as you say, one can probably use Workflow and StateMachine interchangeably. But you should always know what you are using to know how to relate to your object.

Why do you say a State Machine keep running?

See Wikipeida on Petri net > Work flow net.

WF-nets have the soundness property,[20] indicating that a process with a start marking of k tokens in its source place, can reach the termination state marking with k tokens in its sink place (defined as K-sound WF-net). Additionally, all the transitions in the process could fire (i.e., for each transition there is a reachable state in which the transition is enabled).

That is not usually the case for a state machine.

I may be wrong saying "a State Machine keep running". But the opposite is true. A Workflow has an end. A state machine does not need one.

Yeah. But I don’t like the idea that this bullet (or a version of it) is removed.

This is the place where we state the differences and help people choose implementation.

I disagree. The difference is when you need 1 or many places at the same time.
Or in an other shape: It's when you can parallelism or not

As someone who doesn't know much about Workflows, a phrase like the following proposed by Tobias would be easy to understand for me:

Workflows usually have a defined start and end. State machines usually keep running forever.

Also, the phrase says "usually" instead of "always / never", "can / can't", etc. so I guess it's compatible with what @lyrixx is saying too.

I'm really sorry to insist but the main difference is not about this point.
For most application a state machine is enough because there are no parallelism. Then if the need is real, a workflow better fit.

A workflow is more powerful but it comes with more complexity. Some people doesn't understand the sentence "the object must be in all place before the transition". (I'm on my phone, it's hard to make a link)But see related issue about that.

I agree the sentence is totally valid in theory but the choose should not be based on this fact.

I changed my mind. I'm in favour of removing this line.

I still think this line is correct. But it is too complex, not very important and easily misunderstood.

(I just had a conversation with a person referring to this line and said "workflows cannot have loops".)

This change could be reverted, but it's stange to have an introduction that is not main entry point. More over there are no links at the end of the page.

No.. I would say this is very true. But maybe we can express it differently.

Workflows usually have a defined start and end. State machines usually keep running forever.