You baked some assumptions fairly deeply into the debugger and Aaron, as he's want to do, broke them.
I've never seen the SDL debugger code. I was hoping it wouldn't be substantially different from the Windows side (apart from the obvious "different GUI toolbox" stuff). As always, I offer to help get things back together.
(the new "subview" thing in particular is both a major change and rather confusing).
It's just an abstraction. Before, you could have a memory view that displayed an address space or some sort of raw memory (regions, save state data, etc.) And the OSD port was responsible for figuring out all the options in order to display them to the user, and telling the memory view to explicitly display a particular address space or raw pointer.
With subviews, the core figures out all the useful data, and the OSD just has to query the list of them and offer them to the user. This means you get to delete a bunch of code from the OSD and just populate a menu with all the options from the list. When the user chooses one, the OSD just selects that subview by index, instead of telling the core to look at a particular address space or raw bit of data.
However, there are some circumstances where it is useful to know which address space or data a given subview is pointing to, so that data is included with the subview definitions.
In addition, the concept of subviews was extended to registers and disassembly. In these cases, you previously specified a CPU; now you specify a subview instead. It so happens that there is 1:1 correspondance between the two.