Proposed resolution:

This is resolved by p0492r2.

[ 2016-11-10, Billy suggests wording ]

The wording for LWG 2798 resolves this issue as well.

[fs.path.concat] specifies that the postcondition for

path& operator+=(const path& x);
path& operator+=(const string_type& x);
path& operator+=(const value_type* x);
path& operator+=(value_type x);
template<class Source>
path& operator+=(const Source& x);
template<class EcharT>
path& operator+=(EcharT x);
template<class Source> 
path& concat(const Source& x); 
template<class InputIterator>
path& concat(InputIterator first, InputIterator last);

is

native() == prior_native + effective-argument

where effective-argument is

1. if x is present and is const path&, x.native(); otherwise
2. if source is present, the effective range of source ([fs.path.req]); otherwise,
3. if first and last are present, the range [first, last); otherwise,
4. x

It also says that

If the value type of effective-argument would not be path::value_type, the actual argument or argument range is first converted ([fs.path.type.cvt]) so that effective-argument has value type path::value_type.

There are several problems with this specification:

First, there is no overload taking "source" (note the lower case); all single-argument overloads take "x". Second, there's nothing that defines what it means to use operator+ on a string and an iterator range; clearly concatentation is intended but there is no wording to that effect. Third, the final portion uses "value type", but the "value type" of a single character is not a defined concept.

Also, the reference only to [fs.path.type.cvt] seems to imply that any format conversion specified in [fs.path.fmt.cvt] will not be performed, in seeming contradiction to the rule that native() is to return the native pathname format ([fs.path.native.obs]/1). Is that intended?