MultiGraph ↔ NumPy adjacency arrays: what aggregation policy prevents silent semantic loss during conversion?

When exporting a NetworkX MultiGraph to a dense NumPy adjacency matrix via to_numpy_array, parallel edges between the same node pair collapse into a single scalar cell. The multigraph_weight parameter accepts a callable—such as sum, min, max, or a custom function—to control that combination, but the default sum conflates two different conventions: an unweighted MultiGraph yields cell values equal to edge multiplicity, while a weighted one sums attribute values, with no flag distinguishing the two. The reverse path, from_numpy_array, creates at most one edge per ordered node pair, so multiplicity is not recoverable regardless of the aggregation chosen.

Additional boundary risks include silent mismatches in the weight attribute name between producer and consumer, and row/column ordering that follows the nodelist argument rather than any stored node identity. Code targeting NetworkX 3.x should also verify whether the sparse counterpart to_scipy_sparse_array accepts the same multigraph_weight keyword, since helper signatures have shifted across minor releases.

Given these constraints, what aggregation policy best preserves semantic intent when a MultiGraph must cross into array form? Should the conversion API expose a convention flag to distinguish multiplicity from summed weights, or is caller-side documentation sufficient? How can consumers detect that a nonzero cell represents an aggregated set of parallel edges rather than a single weighted relationship?