Completly agree
#The search results view has too many distractions and is not concise and clear enough
cold apex
vocal bay
[I have already responded in the other channel](#db-chat message), but my concern about hiding node results 3 to 6 in your search stack is that, while this may seem intuitive in your case, other users may have a page with a very, very long outline where some blocks as well as the page title match the search string. In such cases, from a UX perspective, it could be annoying to have to open the page first and then search through the entire long outline because the results were hidden from CMD+K search panel due to your proposed rule. It cannot be assumed that the user knows the general content of the page by themselves in all use cases.
As I already mentioned in my other message, I personally liked the previous visual separation of the node search results by node type, namely pages, blocks, and in the DB version also properties and classes (see attached mockup screenshot with section titles between the list items). The disadvantage of this is that fewer list items fit into the command bar field above the fold, but I would argue that the separation into categories makes the search results easier to analyze (at least for me).
This is supported by the idea in information architecture that dividing information into smaller chunks is generally easier for our working memory to process (see Magic Number Seven Theory). However, I think that the compactness of the search results is a valid concern for some users. The other problem with my suggestion is that I don't know how exactly to decide which chunk of nodes should be displayed at the top. In your suggestion, it seems that “pages” should always be at the top. I wonder if other users have experiences where this is not the ideal case.
