Hello Maciej,
Our process definition is quite large and complicated, and we added extra join nodes to prevent the diagram from becoming spaghetti-like. According to the documentation, the join node simply waits the the number of executions specified in the multiplicity attribute (or the number of incoming transitions if multiplicity is not specified) that should arrive before the it gets activated and takes the outgoing transition. This is exactly what happens in JBPM 4.3.
I understand that this change was introduced to address some edge-cases but I think - from the user's point of view - it is a regression in functionality as such usage of join nodes was valid in the previous version.
My feeling is that the assumption, that the process contains the same number of join and fork nodes on every possible execution paths, is not correct and may cause further problems. A lot of people with a bit more complicated process definition migh find that it breaks after the migration to the latest version of JBPM.
Regards,
Peter