I don’t think that is possible. I must say I’ve never missed it. Shouldn’t be too hard to add. One must always choose between UI complexity and functions though.
We have the conventional stack and a chain of choice points. Each of these have a stack as well, each eventually links up with the current active environment stack. I guess it is better to make a picture, but I do not have time now. Hope you get it. We have two types of choice that can be distinguished: those on my parent frame(s) and those that are not. The ones that are not (and thus stand to the right) are subgoals that succeeded with a choice point. If you seek for deterministic last-call optimized code, these are bad. So yes, this helps.
If I recall well, the frames are ordered by depth, but missing values are removed when assigning Y coordinates. Only the relative depth provides information, the absolute value not (and can be huge).
I think you are pretty close to understanding how the stack view works. Note that I’m not claiming it is perfect. It was my first attempt to visualize both parents and choicepoints and I don’t think it was ever changed. Possibly something smarter can be designed. For me it works pretty well 
The main usability issues I have with the debugger are more in easily examining values, why values do not unify (e.g., why no clause matches some goal) and navigating to the interesting point (maybe we need break/spy points with conditions). Notably finding why a deeply nested recursive call finally misbehaves can be tiresome.