I would also like to see subfolders, for the following technical reasons:
- to avoid long pathnames as brought up by the OP. There are ways to enable long pathnames on different OSs, but some programs do not support them and might fail in unexpected ways later on, files might get moved to an even deeper hierarchy etc.
- to avoid too many files in one folder.
- NTFS limit very high, but substantial slowdowns happen even with a few thousand files
- FAT32 (USB drives) has a limit of 65k files. A number that can be reached easily
- to share different subfolders, as suggested by @fredguth and @Vincer
- to interface with other software through automatic generation of .md files in a watched folder
On the other hand, I don’t think subfolders hierarchies are a good way to make information accessible, because one easily runs into many problems, as discussed in an article.
I just wrote a feature request for hierarchical tags, which have many advantages over subfolders, including the ability for one item to be part of multiple hierarchies and no limit on the path length or nesting limit.
From that point of view, I think the subfolder system should be optimized so that the storage issues (no long pathnames and not too many files in one folder) are addressed first, and it should be kept simple enough to make interfacing with external programs easy. If folders serve as an extra tool for organization - that is great, but I wouldn’t sacrifice speed and stability.
Calibre let’s one pick different export formats to convert the internal folder structure, such as {author_sort}/{title}/{title} - {authors}. Logseq could also maintain a set of hardlinks to present a different view for external programs.