Looks fine to me -- @hubert-reinterpretcast, any opinions?

I forgot to explain that where we say:

both of the paths path("//host")/"foo" and path("//host/")/"foo" equal "//host/foo".

This is true even if the separator is backslash not forward slash, because equality is defined in terms of element-wise equivalence, not equality of the native() strings. So the choice of separator doesn't matter, they are both still "equal" to "//host/foo" for Windows even though one of them is "//host\foo" and one is "//host/foo".

The comment "On Windows, backslashes replace slashes in the above yields" should be removed because it's only true for one of "the above yields" not both, so let's just keep the POSIX examples and Windows examples separate.

Looks fine to me -- @hubert-reinterpretcast, any opinions?

Looks okay to me, but I could not make definitive statements with regards to the behaviour for Windows.

I think this example needs more work: these "yields string-literal" examples seem like a bad expositionary device. operator/ on paths produce paths, not strings. If we mean "yields path("...")", then that is what we should write. If we mean "yields a path whose pathname in the (generic|native) format is "..."", then that's what we should write (with a shorthand).

(As is, I can't judge whether this change is correct, because the example is meaningless.)

I'm surprised nobody's mentioned the fact that this example for operator/= doesn't even call operator/=

Maybe we should just rip it out entirely, as I've lost the will to fix it.

I'm fine with just removing the example.

@jwakely: Ping.

@BillyONeal: Hi -- would you perhaps like to take over this issue?

It looks like @jwakely already resolved this with this change, and the discussion about "well the entire example section isn't very good" is a different issue entirely. I think we should merge this, as it is an improvement to the spec, and then move discussions of "operator=/ examples use operator/" to a different, lower priority issue.

It's not just that it uses operator/, Richard's comment at #2098 (comment) hasn't been addressed either.

I agree that fixing the results is an improvement, even if the overall presentation is still nonsense.

I've rebased and pushed a revised commit, PTAL.

It seems like that comment is also unrelated to this change. (Indeed, it also affects the non-Windows examples here)

Indeed. I've tried to address all the problems in the latest commit anyway.

@jwakely, thanks for the updates. I've added a review comment.

@hubert-reinterpretcast, is this agreeable now, in your opinion?

Looks fine to me.