I used to implement file systems for a living. The kind of file systems that people customers spend $$$ on (as much as 6 digit amounts for file system software licenses). And cloud storage users can spend amounts with even more digits. The largest cloud storage contracts in the industry are measured in G$ per year. The kind that individuals or small businesses would never buy for themselves. The kind that runs on the largest computers in the world, whether their exist or not (as far as the public knows).
Some customers want really long file names. Personally, I think those customers are fools, but hey, I get paid to please them. If their workflow wants to store a lot of metadata in their file names ... good for them. So make it work well, and make it efficient. And most important, explain to customers what the limitations and performance impacts are.
Some customers want to have directory hierarchies that are dozens or hundreds of directories deep. Exact same argument as above: If the customer knows the pros and cons, they will usually deal with it like grownups. If we need limitations (like path size < 4096 bytes), explain the "why" to them, and offer them alternatives, like relational databases which have file access integrated into them.
What gets much more interesting is file sizes. Some customers had petabyte file systems with a mean file size of kilobytes, and billions of files. Sometimes a billion files in a single directory. That makes operations like readdir(), ls, and "rm *" fun. At first, we had to do hand-holding with customers who had massive performance problems in such situations. The old joke applies perfectly: "Doctor, it hurts when I do this". "Well, then stop doing it". Then we put lots of R&D into making very large directories and small files work more efficiently (it can never get great).
Other customers have a petabyte file system, and only a dozen files, each about a hundred terabytes. The largest single file I've ever seen was about 50 PiB in size (on an exabyte file system). Customers can get a little angry if they delete a file, and it takes a day or two for the free space in their file system to get back to normal, because the amount of work required to un-allocated all that space, and the fact that unallocation runs in the background. Once you explain it to them, they get less angry. Another good one was a customer who had a policy of deferring all deletes for 120 days (fundamentally, undelete was available for 4 months), and still getting very large bills for several months after they deleted a few giant files. Once you explain to them "you selected the undelete protection, you did set it to the maximum allowed value, and you got the warning about the expected cost", they stop getting angry and start crying instead.
The thing that REALLY gets file system workloads is short-lived data. People who create billions of small files, and then delete each of them after it is 30 seconds old. But expect undelete for 60 days, and offline backup for one year. That's a big problem of managing unrealistic expectations.
So getting back to the original problem: It would be nice if names could be longer, and if paths could be much longer. I fully understand the issues that unicode and UTF-8 create. And how storing metadata in the path string can be a convenient option. But: People who want that kind of unusual performance out of their file system must understand that making this work, and making it work efficiently and reliably, is a lot of extra R&D for the file system implementer. If you are paying a lot of money for your operating / storage / file system licenses and have support contracts, you can have some expectation that your needs and wants will be served; and if they aren't you can take your business elsewhere. If you are using a free implementation, you get what you get, and don't throw a fit. Asking for support is nice ... but "it's too much work and few users want it" is a valid response.
