One of the fundamental characteristics of trees is that topics in a map can have one and only one parent topic (apart from the central topic, which has none). If a node has more than one parent, then the diagram is not a tree, but a network.
Networks are flexible and useful, while trees require more discipline and organisation. They reward this effort by being better at focusing and summarising, because they can be collapsed.
The "single parent issue" frequently appears as an ambiguity in the "best" way to arrange topics - there are occasions where a topic clearly belongs under two different headings at the same time, and needs to be viewed in different ways at different times.
Suppose you are writing a specification for a new project. Starting at the highest level, you can set out the major objectives of the project, then break them down into areas and specific outcomes. But in the real world, projects are never perfectly defined and completely executed. The specification will probably include things that must be done, things that are optional, and things that would be nice if we have spare time, which we never do. The specification is conditional - it is a superset of what might actually happen, and important modifiers are embedded throughout the document.
For the purposes of communicating the project and keeping the detail in context, a top-down description is natural and helpful. But for those who are familiar with the project, this top-down contextual description gets in the way. What they really need is a view of the essential, optional and would-be-nice items so that they can prioritise their work. But if the project specification were drawn up this way, by grouping like items together, it would be much more difficult to get an overview and to interpret the context of a specific "would be nice" item.
This is the "single parent issue" in action. A specific item, such as a project outcome, rightfully belongs both in the context of the wider project, and in the context of its implementation priority. Both views are needed at different stages in the project, and each masks the other, so that living with only one is not easy. There are many other ways to label and group the actions in a project - who is doing them, when they are being done and so on. You can see how databases got invented.
Mind mapping software typically deals with this graphically, as this is a principle of mind mapping. Topics belonging to groups that overlay the organisation of the main tree are marked up with the same markers to represent their group memberships. Colour coding or symbols are used to trigger mental association. If two items in a list of ten are coloured red, then it is natural to assume that they are red for the same reason, and share some common characteristic implied by their colour. You can see at a glance where the red items are, and zoom in on them.
Well, I say "see at a glance". This is only viable if your map is small enough to be seen at a glance. Perversely, this is less likely to be true for electronic maps than pen-and-paper ones. Electronic maps tend to be larger, and rarely viewed or even viewable all at once - which is the value that software brings. A mark-up technique that relies on visual recognition and navigation gets cumbersome if you have to surf the map to find all the instances of a particular marker. There is every chance that you will miss a couple, or get sidetracked on the way.
Mindjet's MindManager has a "Power Filter" tool that allows you to choose markers, then hides everything except the matching topics and their parents. This keeps some of the context of each qualifying topic, but the output is not so easy to work with, and you still need to manually surf a large map to check all the instances. It can also hide related information and surrounding context that could be useful when reviewing the map.
The Power Markers for MindManager add-in from Olympic solves this issue by creating an always-in-view lists of topics organised by marker, so that you can simultaneously see the information in your map grouped in more than one way. In the map window, you can see your specification document arranged as a nicely-organised hierarchy. In the "Hot List" window you can also see topics grouped by their markers, regardless of where they are in the map. Clicking on an item in the Hot List takes you to that part of the map. You don't need to sacrifice your "big picture" to zoom in to selected details. For example, you can see all the "must do" features of your project in one place, and focus on that list, returning to the context of the bigger map when you need to.
This technique is simple on the surface, but actually reveals a lot about the ergonomics of using mapping software. When you are drafting out the big ideas, the map workspace is where your thinking takes shape. The process of building a structure to which detail can be added inevitably brings new insights and ideas. But when you have a working map that you are comfortable with, you more often need to drill straight into specific details to make progress with the project. Many times I have experienced the annoyance of knowing that there is a certain topic in a large map (e.g. with a hyperlink and login details on it), but having to spend time hunting for it, because the navigation from the top level was not actually as clear as I thought it was. Being able to see key topics and go to them in one click provides a wormhole straight to the frequently-used or currently active parts. This spares you the torture of picking through a map that made perfect sense when you wrote it, but seems to have rearranged itself since!
For MindManager 7 and 8 users, you can get a copy of the above map and experiment with it yourself:
There are some subtleties about using markers to ensure items get included in a list of peers, as opposed to using them to visually highlight something in the map itself. The separate Hot List approach means that you can mark topics in a low-key way or even invisibly, while still accessing them as a group. For maps with lots of coded information in them, this avoids the "Christmas tree" effect where the sheer volume of icons and colour coding starts to distract from the flow of the text.
How does this actually solve the "single parent" issue? In the map, a topic can only appear once, under one heading. But in the Hot List, the same topic might appear several times under different headings, controlled by the markers that are applied to it.