It sounds to me like you are going to end up keeping the BGLv1 functional graph concepts for compatibility, and also providing STL-style OO concepts (I prefer this aesthetic too). I'll strive to be compatible with both, if possible.
There are going to be some direct analogs, but they won't be the "same". Different names, (hopefully) clarified semantics, etc. For example, vertex_descriptor and edge_descriptor simply become vertex and edge and are required to be convertible to bool (so you can test to see if they're valid or not). The edge function is replaced by get_edge, with adjacency matrices (eventually) supporting m(u, v). AdjacencyGraph is probably going to go away since adjacency is just an abstraction over incidence. Oh... we don't support "edgeless" graphs, but the BGL doesn't really do that either.
I don't see how the old graph concepts are confining in any way, if anything they are sometimes too loose, e.g. when a node object is self-sufficient and you don't need the graph to lookup its edges. Not that I'm complaining; I understand why they are this way.
They're confining in the sense that trying to model them would actually constrain the design to matching those semantics. We don't want to follow suit. We want to reevaluate and redesign. On a side note, we actually went through a design iteration where we considered making nodes (and edges) self-sufficient. It ends up requiring avoidable overhead for vertex and edge objects in the general case. We didn't want to mandate the additional memory costs, so we're stuck with the same kinds of interface. You need the graph for all of your interesting calls. You can wrap a vertex (or edge)/graph pair to create reliably self-sufficient abstractions. We haven't really explored this design avenue, though.
+1 on all this - I'll be watching with rapt attention, and following your lead.
Maybe we'll have a user in the future? :) Andrew