I have stated this in my discussion with Jakob @futurized that I would like Blocks to be raised at the same level with Pages (have a Graph View, etc).
Actually, in my Opinion, Pages should be a special kind of Block.
So if there were some properties like "is-page:: yes" and "has-file-on-disk:: yes" then any block could be rendered by Logseq a page on disc (either the way of moving the data to the file and keeping the ref in the parent block/journal or keep a sync between the page on disc and the block inside the journal), while there will be much less noise with empty pages that should only be Tags and should appear in the Graph but not as files on disk.
The problem is that if you mark a block as is-page:: yes when a parent block already is a page, you would have two Markdown files sharing a portion of the content. Then when you edit one of them from another tool, how could Logseq handle two conflicting files? It sounds impossible to me.
Another thing that would be nice is Logseq being able to mount some virtual read-only Markdown files. For example the results of a query. There are different ways to create virtual drives on desktop OSes, some more native but a cross-platform approach could be a local WebDAV server. It would be similar to the current HTTP API server but for files.
Pretty well thought, i gave it a read. From my perspective Blocks are treated as a second class Page and I dislike that. So I would like Blocks and Pages to be as similarily treated as possible. That is: to be able to Zoom into a Block and get a graph on its structure (maybe it’s 10-20 sub-blocks deep) and so on, I am sure there are other ways a block is handicapped compared to a page.I am also