Workflow: deal with the unsupported case of looping from a parallel node to the parent fork node

Looping from a parallel node to the parent fork node is currently not supported.
Indeed, after looping, when passing the transitions from the fork node the second time, the engine crashes with the following exception trying to suspend an already suspended node (full stacktrace attached):

org.nuxeo.ecm.core.api.ClientRuntimeException: org.nuxeo.ecm.platform.routing.api.exception.DocumentRouteException: Executing unexpected SUSPENDED state
	at org.nuxeo.ecm.platform.routing.core.impl.GraphRunner.resume(GraphRunner.java:138)
	at org.nuxeo.ecm.platform.routing.core.impl.DocumentRouteElementImpl.resume(DocumentRouteElementImpl.java:88)
	at org.nuxeo.ecm.platform.routing.core.impl.DocumentRoutingEngineServiceImpl.resume(DocumentRoutingEngineServiceImpl.java:41)
	at org.nuxeo.ecm.platform.routing.core.impl.DocumentRoutingServiceImpl$2.run(DocumentRoutingServiceImpl.java:290)
..........
Caused by: org.nuxeo.ecm.platform.routing.api.exception.DocumentRouteException: Executing unexpected SUSPENDED state
	at org.nuxeo.ecm.platform.routing.core.impl.GraphRunner.runGraph(GraphRunner.java:226)
	at org.nuxeo.ecm.platform.routing.core.impl.GraphRunner.resume(GraphRunner.java:132)
	... 32 more

=> Question: how should we deal with such a case?
There are several options:

• When forking the second time we could reset all suspended nodes by cancelling their tasks and assigning new tasks for each node, then we would need to inform the assignees with a relevant message. But what about already terminated parallel tasks?
• We could simply banish this case considering that it does not really make sense, and suggest as a workaround to loop from the merge node to the fork node with 2 transitions from each parallel node to the merge node ('accept' and 'reject' for example) and letting the merge node deal with its input transitions to decide if a loop is needed or not (typically if at least one was a 'reject' then loop).