I have enjoyed taking a break to look at broader issues. My conclusions:
I want to create new, Leonine, tools for studying and adapting code. I am most interested in studying pyzo's gui code and Leo's key-handling code. The goal in each case will be to simplify and improve the corresponding code in Leo.
Initially, such tools are likely to be bespoke scripts. Later, these scripts might evolve into Leonine commands.
The tools themselves will likely be the primary product of the work. There is no guarantee that Leo's code will ever change.
Initial ideas
How could we meld Leo's and pyzo's code bases? We could start with Leo's code, or pyzo's code, or we could start with a clean slate. Each way has advantages. For example, we could investigate snippets in code in what amounts to a unit test.
We can think of Leo outlines as an "executable" graph. Bespoke scripts would define "meaning" and "appearance" of this graph. Other scripts could define projections of a Leo outline onto another (part of) the Leo outline. For example, a script, similar to Leo's clone-find or find-all commands, might summarize the messages which pass between pyzo's gui code. The summary would appear as a single node (find-all) or a tree of nodes (clone-find).
By default, pytest presents its coverage data as a single html page. It might be possible to restructure that data by Leo nodes.
Summary
Melding code bases is difficult to impossible :-) It's a juicy problem, for which Leonine scripts have unique advantages. Scripts can define projections of an outline. Such projections distill information and might form the basis of still more scripts.
Absent significant new tools, the Leonine and pyzoic code bases will likely remain separate. Only strong scripts, similar to unit tests with full coverage, could ensure that changes to Leo's code won't subtly alter the meaning of existing settings and appearance.
Edward
Possibly fitting in with this, I have just discovered SourceTrails