This test was previously tweaked in
321f696920630be1b3c93e2a8b965c624ddd646c to match the output of
of MS STL (except that the MS STL fails on the testcase with an
empty path).
libc++ doesn't produce paths with all normalized separators (and the
spec doesn't mandate it to either).
Tweak the test reference to match exactly what libc++ produces. If
testing with a non-libc++ library, do a relaxed comparison that allows
the separators to differ.
I'm no expert on <filesystem>, but based purely on cppreference, I wouldn't trust path::operator== to do the right thing. It definitely does more than just "separator-agnostic comparison":
https://en.cppreference.com/w/cpp/filesystem/path/compare
I see no problem with D98109 (tightening up the output of absolute). It sounds like you're planning to abandon D98109 and keep the loosey-goosey output, which means the test code will need a "separator-agnostic comparison" function. Instead of using ==, how about making a helper function like PathEq that simply calls .make_preferred() on both paths and then strcmps them? Then we know we're not relying on any other weirdness introduced by path::operator==.