Vertices should have consistent indices during their lifetime

When writing code which mutates a graph instance multiple times, it quickly becomes very complicated to reason about which vertices after the deletion correspond to which vertices before. I believe it would be more natural to keep the "holes" created by deleting of vertices, and fill them again, when creating new ones. Together with the changes proposed in #122 we would be able to get the (now persistent) index of the added node without any extra call to nv(g) or stuff like that.

This change would probably be breaking, mainly because we would need the changes of #122, to retrieve the index where we added the vertex.
I can imagine that such a change might have some impact on memory, since the return value from vertices(g) could no longer be Base.OneTo(n) but has to be some array specifying the available indices. Also for things like adjacency matrices this might be problematic, since we would need to decide how to get rid of the "holes" in our indices.

What do you think? Am I missing something crucial here, that would become very complicated or even impossible to do with this approach?

Start by reading issue #122 and tracing the current behavior of vertex indices, vertices(g), nv(g), and adjacency matrices. The issue needs a design decision about persistent indices, hole reuse, memory impact, and breaking changes before implementation can have a defined completion condition.