It's a big thing to me.
It's clear there are two usage models, then, because I have the same experience as Martin does. It's unfortunate that the filesystem library is biased towards one model and makes the other one difficult to work with.
I don't consider an extra constructor parameter 'difficult'. Sure, maybe the default should be flipped around -- I'd be fine with that. I give much credit to Beman for listening on this issue because personally I found a large lack of support for handling the portable path issue in languages 'perl' that supposedly provide good cross-platform libraries.
I agree, I would be very much against there being two (or more) path types, think of a path as a kind of handle to an object in the filesystem: the issue is what the constructor of path should take as an argument: * narrow or wide character string. * native or portable name. BTW, I've found the paths are usually constructed from a native path string in only one or two place in an application (for example when parsing the command line), all the rest is portable stuff. One thing I am tempted to complain about though: path's checking that a name is legal and portable maybe goes to far - if you are dealing with files that you know already exist, then manipulating that path shouldn't trigger the error checking. John.