We have now drastically reduced the dependency to `.vertices()`

and `.edges()`

in the graph module (except in doctests, but we can specify `sort=True/False`

).

We must now identify the tasks to do and schedule the work.

Some issues to take care of in the graph module:

- #22349 Deprecate sorting of methods
`.vertices()`

and `.edges()`

.
- methods using matrices:
`adjacency_matrix`

, `distance_matrix`

, etc. For all these methods, we can now give as input an ordering of the vertices that will be used to order rows and columns. Currently, we use `.vertices()`

by default. If we switch to `list(G)`

by default, we have to check that it's not breaking algorithms using these matrices.
- methods using
`.relabel()`

. We must check that changing the default ordering of vertices/edges is safe. Should be ok, but we never know...
- methods for isomorphisms were we also have issues with labels (see e.g. #27232 although the case is certainly beyond what we should reasonably do).

- Deprecate sorting of vertex labels in method
`iterator_edges`

of `base/sparse_graph.pyx`

(so of the vertices of an edge). Deprecating this behavior is certainly a hard task. A first step could be to order the vertices according internal integer value, thus ensuring that `(u, v)`

will always be ordered the same way.

And of course, changes done here will certainly break many methods in other modules...