After the refactoring of logseq, block and page have been unified in the storage, with page being a collection of blocks and a block itself; in terms of functionality, we can also see the development team’s efforts to unify block and page, such as the properties that both block and page have. However, in the case of logseq, the core two-way linking function, especially the reference function, is incomplete on the block, i.e. only the page can see the unlinked reference, not the block.
This distinction between block and page in the core functionality limits logseq’s ability to collate long pages - in a context where logseq’s performance support for long pages is already very good (tested a 300,000-word page and, apart from a lag during loading, it loaded very smoothly afterwards). Because, when page A is actually a child of page B, it obviously makes more sense for page A to become a block under page B’s node, but if I don’t want to lose page A’s unlinked reference, I can’t make it a block of page B. If I keep page instead of block, the contextual link is lost when viewing the unlinked reference on the page.
Implementing this feature also helps to solve some of the problems with renamed pages, such as civil procedure law jurisdiction and criminal procedure law jurisdiction. Instead of creating a new jurisdiction page, I can just create a new block in the civil procedure law/criminal procedure law page, because most of the time, creating a new page instead of a block is for features that the page has but the block does not，especially the reference feature.
If the logseq team is interested in this, hopefully the words above will provide some help.
Translated via deepl, I am sorry for any ambiguity.
