I’m still largely pro-file-systems, but your comment made me think. Here’s some loose thoughts, just to get into the problem space. I navigate my codebase at w

I’m still largely pro-file-systems, but your comment made me think. Here’s some loose thoughts, just to get into the problem space. I navigate my codebase at work primarily using the name of the entity I’m aiming to inspect or work on next (e.g. “Popup” or “uiEventStream”) - usually using fuzzy search. This matches by file ame, but feasibly could operate by entity symbolic name to the same effect - increasingly using VSCode’s “find references”, which already operates by entity name (at least that’s now the UI appears) However.. I also use the file tree, because important and meaningful application structure is encoded in the tree. The tree (and its node namez) gives me sections of the app, collections of entity types, and hints how they’re connected. This is invaluable. It helps new colleagues learn the application structure and it helps old hands get to what they want faster. It forms a “silent” background context against which all entity-based decisions get made. The structure could be encoded as tags, with all the files dumped in a single directory. I have yet to see a tagging interface work as well for tag hierarchies as a directory tree works. Tag hierarchies are a specialised use, or extension of generalised tags. Tagging systems typically emphasise (through UI and explanatory notes) the unstructured approach. Structure and unstructure are basically opposed so making a single UI work for both seems problematic. Educating users, most of whom wont use the word “taxonomy” in daily life, how to use a tool supporting a model with an almost inherent self-contraction seems like a mammoth task.