The way it does that is by making 'clones'. So for example, if you have a long program that you find a bug in then you take the node with the buggy code (usually a few lines, maybe 10's of lines) and you 'clone' that node to the spot where you have your bug report or list of tickets or whatever. You then describe the bug, the fix and modify the code (which will modify the original code as well), or you modify the original code leaving the clone as a 'living pointer' to the code to document the location where the bug was found. You add the unit test as another node right where the bug report lives.

The 'thin' model (where you import external files without actually having them present in your outline) is a variation on this theme, another way of doing it is to have the code present in the outline itself and then to export the code whenever the document gets saved.

Both methods have their pros and cons. The biggest con in my opinion is that leo use is not widespread enough that you can expect to collaborate with someone else like this. That means that if you post your project on github or if you share the code with a fellow coder that all that Leo mark-up is wasted. This also likely does not play nicely with version control but I haven't tried that particular scenario myself (I just dump the whole tree in git or subversion and I work on most of this stuff on my own anyway).

I do too. A little idea I have had is to record the paths of developers through this graph of code units and use this information to cluster similar groups of code. This clustering could then inform the way the UI is rendered. So a developer might be working on a code unit and then because this code unit is highly correlated to a set of other code units, these code units would appear prominently in some kind of navigation menu.