Part 3 workflows are not very flexible and require replication (tree-like instead of graphs)

The workflow language as defined in Part 3 is pretty much a tree instead of a graph structure, if I understand the documentation correctly. This is not very flexible and makes workflows that start and end with a single node but split in-between overly complex and hard to maintain.

A process that is a graph such as the openEO process graph looks like this:

A similar workflows expressed in Part 3 workflows looks conceptually like this:

You can also see this in the coastal erosion example, which loads the DEM collection twice:
https://docs.ogc.org/DRAFTS/21-009.html#_coastal_erosion_susceptibility_example_workflow

This leads to duplication, is hard to maintain by users and difficult to parallelize by servers.

The workflow language should ideally be a directed acyclic graph. Languages such as CWL and the openEO process graph allow that. Thus I'm wondering whether another existing option should be chosen instead of creating a new language with limitations that other's have already faced and solved for a reason.

I'm not sure whether it's relevant here, but additions such as (remote) collection input & output can be solved through pre-defined processes for example.

Start by reading the Part 3 workflow definition and the coastal erosion example linked in the issue. Compare the current structure with the referenced openEO process graph and CWL approaches. Done means agreeing on and documenting a directed acyclic graph model that avoids duplicated workflow nodes.