Niall Douglas:
>> I am not sure that "are these two path component the same" can be
>> answered portably - and we probably want that operation to be fast.


Thinking outside of the box here.

Since different components of a path can be on different filesystems and
different filesystems have different rules for storing path, can we
innovate a bit here?

I think representing paths as uniform sequence of char-like objects is
fundamentally wrong. Path should be a sequence of components, like
std::vector<std::filesystem::path::component>. Where each component has
its own encoding.

So we need to add std::filesystem::path::component::encoding and have it
have operator<=> that does implementation defined comparison, char-like
type, etc.

We can have a set of functions returning "Unicode encodings for
paths"... or even like provide full fledged Unicode collation functions
and have encodings' comparison have the same API. Users who would want
to stay portable would use Unicode collation.

It looks like std::filesystem::path is fundamentally broken for now.
Even Linux added case insensitivity on per directory basis so encodings
are stateful in the sense that same file system can have different per
directory rules. Hmm, even the word "encoding" seems to be wrong. More
like std::filesystem::path::component::traits.

So we need:

std::filesystem::path::component::encoding (just to determine the rules
how char-like objects are stored)
std::filesystem::path::component::traits which contains an encoding and
comparison rules at least.
std::filesystem::path::component which is a sequence of char-like
objects + traits. Each component has its own native_type so there is
requirement for type erasure.

Naming may not be perfect. For path_view then we add:

std::filesystem::path_view::component which is type erased view of
sequence of native_type + traits.

I don't immediately see that traits would do any dynamic allocation so I
don't think we need a non-owning version of traits.