If you're referring to adjacency_list, then I can only say that generative data structures pretty much always feel like metaprograms... because they _are_ metaprograms.
Are you planning to move away from generative programming in BGLv2?
With regards to the adjacency list, that's the plan for Origin. Whether or not the rest of the Boost community likes the approach remains to be seen :) It wouldn't be hard to write a generative wrapper around a set of specific data structures to achieve a similar affect. If it was felt that such a wrapper was needed. It's not high on the list of my priorities.
This is no good since a meta-program generates types that may model one of many concepts.
In what way does that make it "no good?"
I think that's a typo, "not good", which is somehow less condemning than "no good" :) The argument comes from a usability perspective. If I want to use a data structure, I expect it to work a certain way---to have a specific interface with guaranteed behaviors. Generative data structures like the adjacency list don't fit that model. All of the generated implementations may be AdjacencyLists, but they're all refinements in one way or another. One side effect of this is conditional document dependent on the choice of selector arguments. Basically, it's a metaprogram masquerading as a data structure, which I perceive as not great. I'm sure there are plenty of people who will disagree.
Another feature that has been on BGL's want list is the implementation of algorithm objects.
For example?
Just a class that wraps the algorithm. There are several in the BGL. The technique offers a little more flexibility when the number of parameters is large. Andrew