They are pretty straightforward: they are just path structures rather than path names that may turn into single strings when supplied to your kernel. Or, depending on the OS maybe only part of the name is turned into a string and part determines which device or syntax applies. All of which is abstracted away by the path objects.

Back in the 1970s when thins first appeared on lisp machines is was not uncommon to use remote file systems transparently, and those remote file systems could be on quite different OSes like ITS, TOPS10 or -20, VMS, one of the lisp machine file systems and even Unix (though Networking came quite late to Unix). “MC:GUMBY; FOO >” and “OZ:<GUMBY>FOO.TXT;0” were perfectly reasonable filenames. Some of those systems had file versioning built into them. So if the world likes like Unix to you some of that additional expressive power could be confusing.

C++17 path support is a neutered version of Common Lisp’s.

Ohh, so they’re kinda like date objects?

Exactly. A pathname in CL is a data structure. Some of its fields are strings, but others (like version) are not.

That makes two of us. But they aren't strings :-)

(Seriously though, is it pathnames you don't understand or logical hosts? Because CL pathnames are actually pretty straightforward. Logical hosts, on the other hand, are a hot mess.)

I don’t really understand how the #P”” “strings” aren’t différent from strings.

They are different types.

  ? (type-of "this is a string")
  (SIMPLE-BASE-STRING 16)
  ? (type-of #P"/this/is/a/pathname")
  PATHNAME

You can't perform string operations on a pathname.

  ? (subseq "This is a string" 5 15)
  "is a strin"
  
  ? (subseq #P"/This/is/a/pathname" 5 15)
  > Error: The value #P"/This/is/a/pathname" is not of the expected type SEQUENCE.

You can perform pathname operations on a string, but only because the string is automatically converted into a pathname first.