This is something that we should look at.

Have done a implementation of this in a feature branch called JENKINS-21010.
https://github.com/Diabol/delivery-pipeline-plugin/tree/JENKINS-21010

My interpretation of the requirements for this is:
Show the relationship between stages. If a task in a stage triggers a task in an other stage, show that relation.
If a task in a stage calls another task in the same stage, do not show that relationship.

Is that correct?

I think the relationship between the stages is probably the primary requirement, but in general it would probably be nice to be able to do both (e.g. if a stage has lots of tasks). Would it make sense to have this be configuration options on the view? Then it would be up to the user to determine whether they want inter-stage, intra-stage or both.

Just previewed the changes: I think it's a start, but the arrows get a bit garbled in the aggregated view and when resizing the window. If you need to reproduce what I'm looking at, our pipeline consists of 6 stages that are configured something like this with the last three in parallel:

A -> B -> C -> D
            -> E
            -> F

Comments:

1. I think the Aggregated view is messed up because the width of the stages in the aggregated view is wider than the normal pipeline views. This is due to combining a long stage name with a long version number. Poking around in chrome to modify the HTML I came up with repalcing this:

<h1>Build - 1.29.816544.20</h1>

with something like this which displays the version number below the stage name (see screenshot).

<h1>Build<span class="version">1.29.820415.81</span></h1>

span.version {
    display: block;
    font-weight: normal;
    font-size: 12px;
    margin: 2px 0px;
}

The widths line up much better and it would make everything more consistent. If the version string is longer than the width of the task divs it would still have this problem, but that's probably unlikely.

2. Would it simplify things to draw the arrows just between the stages instead of the specific task within the stage? It might create less clutter and then you could do something similar to what the build pipeline plugin does to represent parallel tasks.

Thanks for your input.
I agree that the important requirement is to visualize the relationship between stages.
The relationship between tasks can be an requirement on future releases.
Created JENKINS-21435 for your idea on how to fix the problem with both long stage names and versions.

Have done a "fix" for the garbled pipelines when they cant fit into one row. It will now never break the pipeline into several rows.

Merged branch to master. Will be released in 0.7.0 version.

Released