A strictly correct petri net that always eats all tokens is often very, very difficult to construct. Your customers aren't going to be able to do so unless they're familiar with Petri nets, and very few people are. Getting to a clean termination state with no unconsumed tokens floating about the net is very difficult once you start considering exceptions and error handling in your workflow.
Do you have an example of a workflow that customer would want to define on a project, task or employee that an FSM won't handle?
I do miss the GUI and with the old workflow I actually figured out how to hack template pages that could either be displayed by the old workflow's central "tasks" pages as well as stand-alone in the client package's pages (which sorta amazed Lars) ... these are useful things that the current workflow misses. Also the new workflow has some performance issues.
Overall I kinda wished Lars had just written an FSM engine for the old workflow package rather than dump it for a less capable FSM-based workflow package.
In fact my original argument was for the OPTION to use a simpler FSM, not to toss Petri nets overboard entirely. In other words to give the workflow designer the choice.
But having said that, I've not run across a situation where I've actually need the more expressive power of a Petri net. I've seen contrived examples in the paper(s) Lars originally read, but nothing in the real world.
