Python graph_tool: get _all_ shortest paths

I want to calculate all shortest paths between all pairs in a graph. For this I am using graph_tool all_shortest_paths for each node pair in the graph. According to the documentation, the function can take into account the weights of the ribs if specified. At first glance, this works great. However, I found that the list of shortest paths returned is incomplete. This appears to only include shortest paths, which also use the least number of hops from the full set of shortest paths.

Here's a small example:

import graph_tool
import graph_tool.topology

#setup graph
g = graph_tool.Graph()
g.add_vertex(5)
edges = [(0,1),(1,2),(3,2),(0,4),(4,3)]
metrics = [3, 4, 2, 1, 3]
g.edge_properties["metric"] = g.new_edge_property("int")
for i in range(len(metrics)):
    e = g.add_edge(*(edges[i]))
    g.edge_properties["metric"][e] = metrics[i]

#compute all shortest paths from 0 to 2
paths = graph_tool.topology.all_shortest_paths(g, 0, 2, weights=g.edge_properties["metric"])

for path in paths:
    print(path)

print("-"*10)

#increase metric of edge 0-4
g.edge_properties["metric"][g.edge(0,4)] = 2

#recompute all shortest paths from 0 to 2
paths = graph_tool.topology.all_shortest_paths(g, 0, 2, weights=g.edge_properties["metric"])

for path in paths:
    print(path)

      

        
        
        
      

    

It generates a graph with 5 vertices and edges that form 2 paths from vertex 0 to vertex 2, for example:

0 --- 1 --- 2
 \         /
  \       /
   4 --- 3

      

        
        
        
      

    

Obviously, path [0, 1, 2] is shorter than [0, 4, 3, 2] in terms of the number of hops. If no metric is specified, it is correctly recognized (not shown here).

At the beginning of the example, the edges are weighted so that the second path, which has more transitions, is "shorter". The sum of the metrics is 6, while the other path has a common value of 7. Therefore, the algorithm correctly returns [0, 4, 3, 2].

Then the metric of the edge between 0 and 4 is incremented by 1. Both paths now have the same overall value and both should be returned. However, the algorithm only returns [0, 1, 2]. I can only assume that the number of jumps is still somehow taken into account, although I indicated the metric, and therefore the second way is neglected. As far as I know, this behavior is not mentioned in the official documentation.

Am I missing something? Is there a better function to do this, perhaps even in a different library? I've already looked at igraph as an alternative, but it appears to be only able to compute one shortest path for a node pair.