I've hit issues similar to the pointed ones, so I'm interested in such a solution. As a user I agree that being able to use the whole path/aglorithms on different kinds of filesystems would simplify greatly my current work. My use case is to be able to easily choose between real file system and archive file system at runtime. To implement archie file work I currently use PhysFS [1]. However I have several totally different projects with this need of runtime choice of filesystem and currently I have to add project-domain-specific file manipulation layers to each project which is therefore implemented twice, once with boost::filesystem and the other with PhysFS. That's a lot of time spent on making sure they do the same things and it is easily error prone. A solution to help me write my project-specific algorithms once would be very helpful. If the proposal is really applicable without any backward incompatibility, I'm open to test it ASAP in my current projects (if an implementation exists). Also, it seems that it would the solve the same problems for std::filesystem? It was a concern I had recently when thinking about it. Question: it is not totally clear to me what the proposal wants to do with the boost::filesystem::path class exactly. The example suggests that boost::filesystem::path would be usable for any filesystem implementation. In which case, do you suggest to remove absolute() and cannonical() from boost::filesystem::path so that it would only be possible to get these versions using one of the namespace functions overload of the same name, one for local_filesystem(), the other taking a filesystem as parametter? [1] http://icculus.org/physfs/