I've rewritten the reference library for the graph proposal (graph-v3) to accommodate the use of descriptors, which you can find at https://github.com/stdgraph/graph-v3.

Descriptors are a type of handle for vertices and edges, making it a value-based design compared to a reference-base design in graph-v2. Descriptors improve abstraction without changing the core design significantly. The result is fewer concepts (9, down from 18) and function/view overloads required.

Because of the rewrite and the assistance of agentic coding, I've been able to take new approaches to the implementation to get higher quality and greater functionality. Previously missing elements are now complete:

All algorithms and views in the proposal are implemented and tested.
Complete documentation for users and contributors, and for reference, has been added.
93%+ overall code coverage across 4405 tests.

I've also been able to include all the features I've always wanted to support but have never had the time to do. The highlights include

Sparse vertex IDs, implying that vertices are in a container like map or unordered_map. This has been extended so that edges can be stored in a set, map, unordered_set and unordered_map.
Allow non-integral vertex IDs.
Support view chaining (e.g. use of the pipe operator).
Support bidirectional graphs (e.g. vertices with incoming edges).
Reorganize the structure slightly so that the 2 abstract data structures used (adj_list and edge_list) are now presented as peers in separate directories and namespaces.
Add the undirected_adjacency_list graph container to improve test coverage for additional use cases.

If you're familiar with graph-v2, you should be able to adjust easily. You can find all the details of what's changed at graph-v3/docs/migration-from-v2.md at main · stdgraph/graph-v3.

I will be turning my attention to the proposal papers (P3126..3131 and P3337) to align them with the implementation. I hope to have at least one of the papers to review in the next SG19 meeting on March 12.

I'll be weighing how much of the new functionality needs to be incorporated into the proposal. Keeping the proposal lean will be important to speed its acceptance, but there may be negative long-term effects if important things aren't included. I don't anticipate removing anything.