In the code-centric view, the patches are the arcs not the nodes, so quite separate from patch names+manifest file altogether. Hence, the "codebase #16" is not used instead of a patch name but as a default for code states for which the user didn't bother to give a more meaningful name (where they did, such name is used instead). The reason why the patch name is not used for a node is simply that there can easily be cases where there are several incoming arcs to a state (meaning: different patches that result, with hard guarantees, in the exact same code base, basically merging previously different trees or branches).

At any rate, my aim is to have the choice of views and the flexibility wrt granularity/level of detail as one explores a whole set of patches in a given context, not at all to mandate one view for all cases and in all possible contexts. And I certainly agree that in this case where there is just one clear sequence of patches following one another, the patch-centric view fits quite well. The two types of views simply meet perhaps on the need to bring in the corresponding entry from the manifest file and show it more prominently.

For a full patch explorer (or codebase explorer?) aiming to make all levels of information efficiently navigable, I could see it being the other way around.

And yes, a tooltip / hover-hint came to mind as a place to put the descriptions, since it can fit a fair amount of text without expanding the otherwise compact listing. I don't really like though how those are a second-class sort of text which can't be selected or scrolled and disappear as soon as the mouse is bumped; so perhaps something like the MP-WP footnotes where they play more of a supporting or accelerating role to the "real" text which is still found in the normal document flow.

the descriptions from each manifest entry might be worth better highlighting, since they reflect real work done on summarizing each patch yet remain somewhat buried as things stand.

This is a good point and I think it's part and parcel of actually having more helpful ways to explore any VaMP forest, really. More generally, the idea currently waiting to get to the front of the work queue is to literally be able to explore interactively any set of patches, including expanding/contracting the amount of information shown for any given patch at any point. In this sort of approach, the very short description of the codebase state achieved through each patch (or the patch's filename as fallback if such description is not available) is the most basic information displayed but the corresponding manifest entry would naturally be the very next level so perhaps even worth showing as a hint/on hovering over the patch's name.