This request is for the following:

Whenever the user steps into code for which there is no source available, rather than automatically
smart stepping, have the debugger display a dummy editor with a "Source not available" message. At this point, the user 
should still be able to see local variables, threads, and call stacks. I would also expect that step-into/step-
over/step-out/resume actions behave as normal. In addition there will be a "Smart Step" action that enables under 
the "Source not available" condition (I'm thinking this would look something like a DVD fast-forward/skip button). If 
they press "Smart Step" it will then advance the current thread until source is once again available. 

Since this would be a new, non-standard debugging feature, you might have the "Source not available" message display a 
tooltip advising them to use "Smart Step".

There are a number of things that you get from this:
a)Even if source is not available, being able to see stack and local variables comes in handy quite often. For example, 
there will be some expression that gets evaluated and passed as an argument to a method for which you don't have source 
configured. If you can step into that method without automatically smart stepping, you can view the value of that 
variable. By smart stepping you always lose that information. Another place where it comes in handy is if you have a 
non-source breakpoint set (like setting a breakpoint on an exception) - being able to suspend and view stack and locals 
even if you don't have the source code available is huge.

In our core product, we integrate with a lot of third party closed-source products. Having rudimentary source-less 
debugging is an invaluable feature for those cases. I think there's a separate feature here for "Support Source-less 
debugging" where this is taken one step further and display the dissassembled java bytecode rather than just a "Source 
not available" message. This would be a very nice feature to have.

b)It eliminates the element of surprise of smart stepping. When I was first using the Netbeans debugger, it took a 
while to figure out that it was doing smart stepping. From the user's standpoint, you will step into some method, the 
debugger looks like it goes off into "la-la land". If it's long enough, people think it has hung and kill the debugger. 
I know I've done this a number of times. Now that I am aware of this behavior, I can work with it, but admittedly I 
still get caught by it from time to time. 

c)It facilitates heterogeneous language debugging. For example, we have a debugger for an interpretted language. When 
running the two debuggers at the same time, it is easy to accidently step-out from java into the interpretted language. 
At this point debugging becomes extremely sluggish as the java debugger tries to smart step through the interpretter 
code (the interpretted language's interpretter is written in java). You are left with no choice but to kill the 
debugger. If the user were given an explicit choice to engage smart stepping, they could then simply "resume" the java 
debugger and all would be good.