I've used and liked mind maps very a long time, and I'm very picky about their appearance. I started with Tony Buzan's book, before there were programs to make mind maps. Mind Maps were among other things an excellent memory aid for me. I used to take meeting notes as mind maps in real time (by hand), and I found time after time that I could pick up one of them say five years later, and in five or ten minutes I could reconstruct the whole meeting. I also taught several graduate level classes using mind maps as my lecture notes. It worked wonderfully well.
I dislike almost all the mind mapping programs out there that I've tried, including the Brain, mostly because their appearance doesn't suit me, or the way you interact with them works poorly, etc., etc. I used to use the old Mind Manager product (I'm talking 15+ years ago) and liked that pretty well. But now the successor is way too complex and garbaged up, and pretty expensive to boot. So I don't use it.
The one thing a mind map doesn't do is to show incoming edges - that is, "predecessor" nodes. That's not a bad thing, but it prevents one from moving freely around a large knowledge base. It's not the intended use of mind maps, so it's not defect in the basic idea. If you want to make effective use of a knowledge base it's a weakness, one that The Brain has tackled. But because of the emphasis on "thoughts", the Brain is weak on the relationships, which is where the real meat of a knowledge base is or should be. And I don't like the way their displays shift around.
The zettelkasten approach is as you say about notes, but that's a superficial view. It's much more about the connections, and also, if we go along with the original, the "notes" are intended to be carefully thought out summaries of various thought fragments, not simply reminders dashed off in a hurry.
Leo's basic structure of a node for everything has proved to be quite wonderful. It is limited a bit because the nodes are text only, but that's for the most part livable. A node has a single incoming edge (not counting clones - clones introduce a sort of hybrid model, and I don't want to get into it here). So if we want to have a node with multiple incoming edges, and outgoing edges that link to nodes that aren't "child" nodes, we need to carry more information, and we need a way to visualize and navigate the system.
There are many ways to carry more link information. For the zettelkasten system I worked out some time ago (there are one or two threads on that from a year or more ago) I use gnx identifiers (Leo's internal node ids) with notation in each node's body to define a link. For my browser bookmark manager - still in progress - I use Leo's UNL paths to construct internal links each time a display is built. One could also use UAs (User Attributes) though I haven't felt the need to so far.
It's the visualization and navigation of any system that is based on graphs that's the hard part. It's hard both from a design/UI point of view and from an implementation point of view. The really nice part of basing these systems on Leo is how easy it is to reorganize, restructure, and edit the information. I have found that to be a real strong point. The disadvantage is that there is no intrinsic graphical subsystem/API for displaying the information (preferably with links).
I'm inclined to think that using Graphviz may be good for generating some of these displays. Since Graphviz is a stand-alone console-based C program, it may turn out that a server is needed to interact with it effectively. Leo already has the skeleton of such a server, and the leointeg project (that lets you work on Leo outlines in Visual Studio Code) is a proof of principle.
Whew, that was longwinded! If you want to pursue this subject further, we should probably start a new thread. You can see that it's a topic I'm very interested in.