I'm afraid it's completely incorrect to map extended attributes to classic attributes.
I think we need new ExtendedAttributes (or something like) on both Unix and Windows.

Please see my other comment: https://github.com/dotnet/runtime/pull/52235/files#r625991197

@iSazonov, you wrote in the other comment:

I'm afraid it's completely incorrect to map extended attributes to classic attributes.
I think we need new ExtendedAttributes (or something like) on both Unix and Windows.

I completely agree with you that we should have an ExtendedAttributes property. It would solve the problem of having them intermixed with normal attributes.

Extended attributes apply to BSD, Linux, OSX and even for Windows, in the form of Reparse Points.

But as you can see, UF_HIDDEN was already being read in the old code before my PR, and I just made sure it was consistently retrieved in FileSystemInfo, FileSystemEntry and FileStatus.

I agree that it's not an either-or scenario: A platform-specific ExtendedAttributes property definitely makes sense, but it also makes sense to map the UF_HIDDEN flag to a platform-abstracted Hidden attribute (for instance, to the macOS Finder (file manager) both UF_HIDDEN files and files that observe the general Unix name-based convention (name starts with .) are hidden.

Has this ExtendedAttributes property been discussed at all?

Note that macOS has open-ended extended file-system attributes, similar to NTFS alternate streams (use xattr -s -l /tmp to see an example on macOS), but - if I understand correctly - NTFS alternate streams aren't supported (yet) in .NET, so that's probably a discussion for another day.

Has this ExtendedAttributes property been discussed at all?

Yes, we have a relatively new issue tracking this request: #49604

Let's take the conversation there.

But as you can see, UF_HIDDEN was already being read in the old code before my PR, and I just made sure it was consistently retrieved in FileSystemInfo, FileSystemEntry and FileStatus.

It was added at 5.0 milestone without in-depth analysis.
I'd suggest to pass the design through in-depth analysis and API review.
My main concern is that it (chflags) is absolutely another API with specific behaviors and specific error codes.
I have not found a standard for these attributes. The most comprehensive list is https://www.freebsd.org/cgi/man.cgi?query=chflags&sektion=2&manpath=freebsd-release-ports
As we can see there are references to DOS, Windows and CIFS FILE_ATTRIBUTE_* attributes. I don't understand what that means and what the design intentions is.
If there are no standard behavior definitions, I would make different APIs to avoid intractable problems in the future.
There's an attribute mapping, but we can't map "." in UF_HIDDEN.
Perhaps the trend is to abandon classic attributes altogether and only use extended attributes. In that case, we definitely shouldn't mix them.
Since the docs speak about "mapping" then surely this API must perform "." mapping in UF_HIDDEN.
The final thought is that we need to be consistent with the other communities (Java, Python, ...).

After taking a look at #49604 it occurred to me that what we are talking about here is not a case of extended attributes, as the latter are user-definable data with no special meaning to the file-system or the system.

By contrast, the so-called file flags on macOS / FreeBSD - of which UF_HIDDEN is one example - do have system-defined meaning, analogous to the file attributes on Windows.

These file flags do not map cleanly onto the born-on-Windows System.IO.FileAttributes enumeration, though mapping UF_HIDDEN onto Hidden is currently partially implemented:

Examining an enumerated FileSystemInfo instance does surface UF_HIDDEN as the Hidden attribute in .Attributes, but the enumeration itself does not consider such files hidden.

Curiously, the same inconsistency applies to the ls utility on macOS (my guess is that the following also applies to FreeBSD): ls lists UF_HIDDEN files as if they weren't hidden, but ls -lO does list all file flags (including UF_HIDDEN as hidden, the name also used by the chflags utility).
When POSIX-compatible shells on macOS perform globbing, they also do not consider UF_HIDDEN files hidden.

By contrast, Finder, the macOS file manager, equally considers .-initial names and UF_HIDDEN files hidden.

De facto the .Attributes property is already being used to map non-Windows concepts onto the equivalent Windows concepts:

• Symlinks on Unix-like platforms get the pseudo attribute ReparsePoint
• The user-specific lack of write permissions is mapped on to pseudo attribute ReadOnly

To me, these mappings make sense, but I agree that they should be thoroughly reviewed, with a view toward extending this mapping; e.g., UF_IMMUTABLE and SF_IMMUTABLE are candidates for mapping onto ReadOnly too.

With respect to UF_HIDDEN, we need to decided whether (a) we want to resolve the current inconsistency and, if so, (b) in what direction.

Consistently mapping both .-initial names and UF_HIDDEN files onto Hidden is defensible, even though in the world of shells it would make PowerShell's behavior then differ from that of ls / POSIX-compatible shells.

then surely this API must perform "." mapping in UF_HIDDEN

I don't think so: it seems fine to me to map into one direction: to have the platform-abstracted Hidden attribute reflect whether the file is effectively hidden, irrespective of the mechanism used, and on macOS / FreeBSD there happen to be two mechanisms available, both of which are - unfortunately only partly - honored by the system.

If we were to introduce a dedicated API for macOS / FreeBSD file flags (again, this is not the same as extended attributes), then it should obviously reflect the true flag values only.

After taking a look at #49604 it occurred to me that what we are talking about here is not a case of extended attributes, as the latter are user-definable data with no special meaning to the file-system or the system.

Yes, I suggest to use another terminology here - file system flags/ fsflags/ FileSystemInfo.Flags.

Since mapping is very questionable and may cause breaking conflicts in the future, I suggest avoiding it now and only presenting it in some way.
The application can be fixed faster than .Net. For example, PowerShell will be able to handle UF_HIDDEN in a special way and this can be changed in any intermediate version, unlike .Net which will remain stable from version to version.