filesystem::copy doesn't create a symlink to a directory in this case:

copy("/", "root", copy_options::create_symlinks);

If the first path is a file then a symlink is created, but I think my
implementation is correct to do nothing for a directory. We get to
bullet 27.11.14.3 [fs.op.copy] (3.6) where is_directory(f) is true, but options
== create_symlinks, so we go to the next bullet (3.7) which says
"Otherwise, no effects."

I think the case above should either create a symlink, or should
report an error. GNU cp -s gives an error in this case, printing
"omitting directory '/'". An error seems reasonable, you can use
create_symlink to create a symlink to a directory.

So 3.6 catches create_symlinks | recursive but I believe we want 3.X to handle it instead.

[2018-01-26 issues processing telecon]

Status to 'Review'; we think this is OK but want some implementation experience before adopting it.

[2018-01-29 Jonathan says]

The proposed resolution for LWG 2682 has been in GCC's Filesystem TS implementation for more than a year.
It's also in our std::filesystem implementation on the subversion trunk.

[2018-06; Rapperswil Wednesday evening]

JW: can we use the words we are shipping already since two years?
BO: what we got is better than what we had before
no objection to moving to Ready
ACTION move to Ready
ACTION link 2682 and LWG 3057 and set a priority 2 and look at 3057 in San Diego