1) Not from the keyboard. If you're using the editor and have the Editor Toolbar displayed, there's a "Stack" dropdown that shows you the entire call stack, and you can jump to an arbitrary level. You might be able to hack an n-level dbup/dbdown together by looking at what's in that dropdown, but debugger control is very hard to script from Matlab due to the interaction of the debugger and the M-code you're using for scripting.
2) If you issue a command from the "K>>" debugger prompt, when it finishes it ought to return you the the stack level you issued it from, like you expect. Do you still have the breakpoint set at the bottom level of the code? Maybe you're actually seeing a secondary debugger "K>>" prompt from a breakpoint in the nested call stack. You can essentially have multiple nested debugger contexts.
For example:
function f1
f2();
function f2()
f3();
function f3()
f4();
function f4()
disp('Hello world');
If you throw it in the debugger like this, you'll hit the breakpoint at the bottom of a call stack which itself was launched from the original debugger session.
>> dbstop in f1 at 8
>> f1()
8 disp('Hello world');
K>> dbup
In workspace belonging to f1>f3 at 6
K>> dbup
In workspace belonging to f1>f2 at 4
K>> f1()
8 disp('Hello world');
K>> dbstack
> In f1>f4 at 8
In f1>f3 at 6
In f1>f2 at 4
In f1 at 2
In f1>f4 at 8
In f1>f3 at 6
In f1>f2 at 4
In f1 at 2
K>>
Doing a dbquit (getting out of the nested debugger session) gets you back to the middle of the original call stack where you left off.
K>> dbquit
K>> dbstack
In f1>f4 at 8
In f1>f3 at 6
> In f1>f2 at 4
In f1 at 2
K>>
If you dbcont out of your "K>>", then control flow will resume from the bottom of the call stack, where the breakpoint was originally raised, regardless of what stack frame the K>> is looking at. You can't use the debugger to change the control flow of the mainline code being executed.