Would you mind elaborating as to what’s too limited about a file tree structure?
More to why I’m asking:
I get that filenames including emoji’s or other non-ascii characters (allthough utf-8 being quite widely supported these days) can be problematic, but that doesn’t seem to outweigh the advantage of being able to have the knowledge base structured on the fs level. I fail to understand I even have to explain the advantages, I guess I’m not young anymore. I’ve switched from Obsidian to logseq because it’s open source, but I’m really considering to go back since this whole namespace thing hinders the consumption of the content as you’re seeing the same information over and over again. Eg. in a technical documentation I’m describing how various behaviors have their effects on code and enforce clean separation of concerns, seeing the word Behavior highlighted inside a single page over 20 times because it’s the namespace parent of eg. Timestampable, just gives me headaches after a while. I want to use the logseq namespacing stragegy but it just ignores my carefully organized and git tracked collection of content.
Meanwhile I’ve seen how extensible logseq really is as there is already a git repo out there that addresses this and other tweaks very nicely, but if the logseq team insists on this feature being an external project instead of taking advantage of the fs without very good reasons - I’ve seen none so far - makes me kind of doubt if I should keep using it.
I like to read markdown / copy paste it with formatting into eg. an email, from for instance Gitlab or other web-based platforms providing markdown parsing (including mermaid) but with the current namespace implementation this is a pain as I have to manually update all [[]] links to traditional style markdown link syntax . The fact that Obsidian does this out of the box, automatically recognizing nested files whilst maintaining a title-only rendering and usage, blew my mind and got me really motivated to continue writing documentation about complex topics. Seeing the graph grow seemingly out of nothing is a great motivational factor for me.
Call me old or stupid, I don’t care, but as a markdown lover, working with logseq namespaces has become a serious downer for me: it gets me out of my writing flow as it’s just distracting and objectively harder to read over the repeated highlighted parent namespaces, doesn’t reflect any structure in any other markdown viewer, refuses to place new documents into folders that already exist on the fs, creates these weird looking filenames with double __, just to name a few… This has become a real vendor lock-in and I oppose that wholeheartedly.
This very topic already contains great arguments as to why this decision of the team is hard to defend, so I’m really curious to how your vision came to fruition. I hope I can be enlightened instead of becoming more and more disappointed as hierarchy means a lot to me and carefully crafted directory structures are a thing, just look at how your average software project is structured…
I’m obviously not talking about repositories with 10k files etc as I’m mostly using this for personal or private topics. If I ever have to deal with that kind of large amounts of data I sure hope I have a better tool than an “always deprecated” electron app anyways. I strongly believe the focus should remain on Markdown, the content and the act of writing. Reinventing a well established concept like hierarchy really brings more pain than gain at this point…
Look, if there were technical reasons preventing this from already being a built-in feature of logseq, I’d be more than happy to wait, but if the team has already decided that this will never be a thing, you’ve lost a once enthousiastic user. I was about to launch logseq as the next documentation tool for a large governmental institution, but as long as filesystem based hierarchy is simply ingored and discared by logseq, I won’t as I’ll just be grilled by all the old-skool technicians I have to deal with.
I really hope the team can change their vision on this topic and I will definitely reconsider as soon as I see even a roadmap mentioning this 
I have to admit: I kind of overlooked this topic:
still reading on 