The short answer is that gvpack does not declare edges between subgraphs. Indeed, when there are common node names between subgraphs, gvpack renames them to avoid collisions. However, this can be eliminated.
For example, for three .dot 1.dot files:
digraph { A -> B A -> C }
2.dot :
digraph { D -> E E -> F }
... and 3.dot :
digraph { D -> G G -> A }
... running gvpack -u 1.dot 2.dot 3.dot | dot -Tjpg -ogvp1.jpg gvpack -u 1.dot 2.dot 3.dot | dot -Tjpg -ogvp1.jpg gives the following graph gvp1.jpg :

As you can see, gvpack replaced duplicate node names. However, we can easily reverse re-marking with gvpack -u 1.dot 2.dot 3.dot | sed 's/_gv[0-9]\+//g' | dot -Tjpg -ogvsub.jpg gvpack -u 1.dot 2.dot 3.dot | sed 's/_gv[0-9]\+//g' | dot -Tjpg -ogvsub.jpg gvpack -u 1.dot 2.dot 3.dot | sed 's/_gv[0-9]\+//g' | dot -Tjpg -ogvsub.jpg , which creates the following gvsub.jpg graph:

This approach is based on subgraphs with common node names, so to achieve this, you may need to insert additional nodes into the subdivision .dot files.
(EDIT: The above solution showed a graph with merged nodes, but not with subgraphs in clusters. The following solution shows subgraphs in clusters.)
Given the .dot files 1.dot files (they match the files above, except that I gave each organ name):
digraph g1 { A -> B A -> C }
2.dot :
digraph g2 { D -> E E -> F }
... and 3.dot :
digraph g3 { D -> G G -> A }
... along with hdr.dot :
digraph GMaster { compound = true; g1 [style=invisible, height = 0, width = 0, label=""]; g2 [style=invisible, height = 0, width = 0, label=""]; g3 [style=invisible, height = 0, width = 0, label=""]; g1 -> g2 [lhead=clusterg2, ltail=clusterg1]; g1 -> g3 [lhead=clusterg3, ltail=clusterg1]
... and tail.dot :
}
... we can run cat 1.dot 2.dot 3.dot | sed 's/digraph \(\w*\) *{/subgraph cluster\1 { \1/' | cat hdr.dot - tail.dot | dot -Tjpg -oclust1.jpg cat 1.dot 2.dot 3.dot | sed 's/digraph \(\w*\) *{/subgraph cluster\1 { \1/' | cat hdr.dot - tail.dot | dot -Tjpg -oclust1.jpg cat 1.dot 2.dot 3.dot | sed 's/digraph \(\w*\) *{/subgraph cluster\1 { \1/' | cat hdr.dot - tail.dot | dot -Tjpg -oclust1.jpg to provide the clust1.jpg file:

Thus, in the header file, I added an invisble node with the same name as the subgraph to each subgraph, using compound=true to allow edges between the clusters. I indicated the edges to draw between the clusters, and I set lhead and ltail for each of the edges between the invisible nodes to ensure that the right cluster is used as the head and tail of each of these edges, I also added a corresponding invisible node for each subgraph in the process transform each subgraph into a cluster using sed .
The edges between nodes D, G, and A are shown because these nodes are common to clusters. In addition, each of them is displayed in only one cluster. If the nodes were unique to the clusters, the only edges that would be shown between the clusters would be the edges between the invisible nodes. This can be seen in the following graph, where I renamed the nodes to 3.dot :

There is another drawback that I could not fix. Invisible nodes still take up little space, so the cluster boxes look one-sided because invisible nodes are located next to visible nodes. This also means that the heads of the edges between the clusters point to one side of the cluster block, and not to the middle. Currently, I canβt understand what can be done about this if we are not ready to look at each subgraph and find the node that is already in this subgraph / cluster to serve as the node representative for this subgraph / cluster (i.e. the one on which we take the edges for this cluster). This can be done quite easily manually for several subgraphs, but it would be tiring if there were many subgraphs.
On the contrary, the approach I used above only requires that we know the name of the cluster and can insert it into the hdr.dot file.
I built the hdr.dot file manually for this case, but the contents of the hdr.dot file can be extracted from other .dot files using sed , awk , perl or python if necessary. The script can also insert edges for cluster bindings in hdr.dot if information about which clusters should be connected is available somewhere.