I read it, even though you could be succintly making your points here instead of linking generic articles, and that's why I surfaced the only thing I considered valid.
The usecase you bring up, including the multiple scripts issue, is search. And it's not and should not be a filesystem concern which optimizes for a different kind of access from which you can build search on top of.
The article is not generic, it is spesific to the issue being discussed, and it explains the issue better than I can.
"And it's not and should not be a filesystem concern which optimizes for a different kind of access"
Why not? Is that by Pope's decree, or is there an actual reason for that?
The filesystem already has like 3 different APIs, with and without caches, sync and async, so clearly they do optimise for different kinds of access.
Can you demonstrate a tool that can search efficiently in different alphabets, or when the same character is presentes by different unicode codepoints?
> Why not? Is that by Pope's decree, or is there an actual reason for that?
By the decree of it vastly increasing complexity and drastically changing the very generic problem a filesystem tries to tackle, instead of just isolating it to its own solution for when it's actually needed and the trade-offs make sense.
> with and without caches, sync and async, so clearly they do optimise for different kinds of access.
That are compatible with the previously existing patterns. Case-insensitive/mapped codepoint full-text search is a very, very different problem and for which you should reach out to the right solution.
And if you want it in your file browser, well nobody's forcing your operating system's human-facing file browser to base its UX entirely on file system primitives.
As for existing tools, I don't know, I don't care for them since I can just organize my files and find them with fd or use a mapping tag-based file-system like tmsu. But I would assume this is the kind of usecase KDE's Baloo or GNOME Tracker intend to solve.
