Choosing NetworkX Graph vs MultiGraph for Production Data with Duplicate Edges

When building a NetworkX graph from an edge list that may contain multiple edges between the same node pair, the local test set often contains no duplicates, so a simple nx.Graph works. In production, duplicate edges appear and the Graph class silently overwrites the attribute dictionary of the existing edge, keeping only the last set of attributes.

The alternative is to use nx.MultiGraph, which preserves each parallel edge with a distinct key, but this changes the shape of edge‑access tuples ((u, v, key, data)) and makes neighbor lookups keyed, while the auto‑generated keys are not stable after modifications. The decision hinges on whether to preprocess the data to merge duplicate attributes into a single edge or to adopt MultiGraph and update all downstream algorithms to handle keys.

Should duplicate edges be merged into a single attribute dictionary before insertion, or should the codebase switch to MultiGraph and adapt edge‑iteration logic? How does the choice affect attribute preservation, traversal complexity, and the stability of edge identifiers in subsequent graph operations?