The major use I thought of is a scene graph. This typically consists of a large number of nodes ( Can be many Mb file) many containing structures of points and transforms. I suspect its cheaper to keep these in memory in their binary format rather than as strings.
What you need to store a scene graph is a generic tree container, not ptree. Property tree is for storing properties. Anyway, if you want you can consider customizing data type to be some sort of Object *, but I don't know if this is going to take you very far.
Whatever... it would be interesting to see the rationale behind the design decisions made within the documentation. I *think* that a trade off has been made in favour of convenience and 'light weight' (I think it would not perform well on large files for example)
Yes, being light-weight and easy to use it the main goal. I think this is said in the introduction part of the docs.
Is it necessary to make key a string. Could it not also be (say) an integer id?
Library would need some sort of path parsing policy. I think that the only required function would be to separate head of the path from the tail (sort of Lisp-like behaviour). This is quite an interesting proposition, I consider it the most valuable addition to the library at the moment. Thank you, Marcin