However, building property maps is pretty trivial: it's just a structure with 1-3 operations and a couple of free functions.
I agree. But if I am going to write a property map class with operator[], then why should I have to write a global put, or a global get, or "global put and global get" when I can use template helper class(es) to automate that task for me. Rewriting very similar code is tedious and error-prone because it is tedious - I'm speaking from personal experience of writing put/get global functions and forgetting a const here or a reference there ... And the problem with forgetting references is that the compiler doesn't complain and I will potentially incur a runtime penalty which will be hard to track to down. (Just because something is trivial, doesn't negate the possibility that it will be tedious or error prone.) Currently if i want to avoid rewriting code that can easily be automated (via templates) I'm relegated to using put_get_helper which gives me both put AND get global functions. This is undesirable for reasons I've outlined in my rationale in my first post.
I don't really see the need for an expanded framework to help build them.
From a client's perspective it's not needed, but it will be very useful in helping to avoid missing reference mistakes and in reducing what needs to be coded.
As for an "expanded framework", what I'm proposing is pretty trivial change to existing code and what's more it's entirely backward compatible (<----**emphasis**), so no other preexisting code using BGL needs to be changed to accommodate my proposition.
You might also consider that the BGL is fairly dated and stagnant, and in need of some serious TLC. Whether or not property maps continue to exist in the same form in future renditions of the library is anybody's guess - I'm leaning towards "no".
Valid point. But if for the next release(s) of BGL no changes have been made to property maps, I would argue that my original proposition will be a non-trivial aide for clients of the library.