LANG=en_IE.UTF-8
    LANGUAGE=en_IE:en
    LC_CTYPE="en_IE.UTF-8"
    LC_NUMERIC="en_IE.UTF-8"
    LC_TIME="en_IE.UTF-8"
    LC_COLLATE="en_IE.UTF-8"
    LC_MONETARY="en_IE.UTF-8"
    LC_MESSAGES="en_IE.UTF-8"
    LC_PAPER="en_IE.UTF-8"
    LC_NAME="en_IE.UTF-8"
    LC_ADDRESS="en_IE.UTF-8"
    LC_TELEPHONE="en_IE.UTF-8"
    LC_MEASUREMENT="en_IE.UTF-8"
    LC_IDENTIFICATION="en_IE.UTF-8"
    LC_ALL=

The APIs, Win32 in the case of [1], have further restrictions. If you want you can use a different API/personality and write whatever value you'd like (sans NUL and /) provided said personality has no limits -- NTFS does no validation itself.

In practice, Win32 being the default personality makes said plethlora of restrictions true, but it isn't a "filesystem" limitation, rather an API restriction. A nuanced if unimportant difference.

If you look at OS-X there are similar issues. The Apple File System is case insensitive for a particular Unicode version.

Win32 ?

Also, backspace is locale dependent. In some languages, backspace removes the accent, which makes sense with combining characters, and other it removes the whole character. Which is going to be fun when whole syllable is code point.

Languages are hard, there is no way to make them simple.

I don't think we're there yet. I think if someone did make a complete list of "valid" emoji right now, which for the sake of argument I'll call "formally defined in the Unicode standard", it would even on an absolute scale look like we're a long ways away from a full 32-bits of valid combinations. But you have to think of this on the log scale because this is about "bits" and those four-person families are already quite a long ways along to a full 32 bits. It wouldn't take much more customization, or the formal addition of more people in a group, to get there.

And someone who knows more about Unicode than I do may be able to establish that there are already in the standard ways to get to more than 32 bits' worth of data in a single standardized glyph; I certainly wouldn't bet much against that already being true.

(Personally, I'll go with "worse". In hindsight, we should probably have frozen Unicode into the original Docomo (and the other phone company that had them) emoji necessary for interoperability, and then created the emoji as an extension into Unicode. It seems like it would be useful to "support Unicode" without having to come with the complete understanding of what is increasingly the most complicated "language" in Unicode; forget doing good Arabic rendering or trying to understand an ideographic language, the emojis blow all that complexity away now. But here we are.)

[1]: https://unicode.org/emoji/charts/emoji-zwj-sequences.html

[2]: https://www.unicode.org/reports/tr51/#Multi_Person_Groupings

Why not? They're just two (or more) characters from a special set next to each other that a font may combine. (and some ad-hoc ZWJ sequences) I don't think windows even ships a font that does that by default.

If you change the locale to an uninstalled one, then yes. But if the locale is installed, then I don't see a problem.

echo $LANG

# output: en_US.UTF-8

touch fusée.txt

LANG=fr_FR.UTF-8 ls

# output: 'fus'$'\303\251''e.txt'

sudo locale-gen fr_FR.UTF-8

sudo update-locale

LANG=fr_FR.UTF-8 ls

# output: fusée.txt

Are you maybe using non-UTF-8 locale?

POSIX 2024 encourages (but doesn’t require) implementations to disallow newline in file names, returning EILSEQ if you try to create a new file or directory with a name containing a newline. Thus far Linux hasn’t adopted that recommendation, but I personally hope it does some day.

For backward compatibility, it would have to be a mount option. It could be done at VFS level so it applies to all filesystems.

Personally I would go even further and introduce a “require_sane_filenames” mount option, which would block you (at the VFS layer) from creating any file name containing invalid UTF-8 (including overlong sequences and UTF-8 encoded surrogates), C0 controls or (UTF-8 encoded) C1 controls.

Also I think it would be great if filesystems had a superblock bit that declared they only supported “sane filenames”. Then even accessing such a file would error because it would be a sign of filesystem corruption.