As I've written on this subject before, I think current debuggers largely miss the point, though gdb misses the point in a whole different league.
What I want from a debugger is 99% of the time met by gdb by running a program and running a backtrace and inspecting a few variables. Where gdb falls flat by default is in making me type in commands to get a register view, backtrace, disassembly of the current area, and the current stackframe.
Most other debuggers do ok there. But even with gdb it's trivial to define a few macros to make that part easy.
Where every debugger I've used falls flat is that for most harder problems, their functionality seems focused on heaping on functionality to let me do the job the debugger should have, instead of actually doing the things that would really save me time.
I've increasingly instead turned to valgrind as my first choice, for the simple reason that a huge portion of the problems I deal with are low level (e.g. debugging my compiler, which involves debugging things like why my code generation doesn't correctly initialise a value on the stack. But this is the same problem I generally would like to be able to debug in higher level languages:
Program crashes. Which value caused the crash, or caused the exception to be thrown? When was that value set? Where? What was the code paths that led to that value being set? Which variables contributed to it being set to that value?
Fully automating this in the general case is not possible (it devolves to the halting problem if you don't put the debugged program in a "black box"), but making it easy for a human to guide it there should be the priority for a debugger.
Being able to get a quick view, see that "huh, that value shouldn't be there", be able to tell the debugger "identify when that variable will change and re-run", and work your way back that way, would solve the vast majority of the tough debugging sessions I've had.
Note that the above is not the same as just setting watch-points by tracing and checking. Handling of watches is usually crude in most debuggers. What I'd like is something similar to Valgrind - to do this well the debugger needs to at least analyse the code and intelligently pare down what it watches, and ideally dynamically translate the code into something sufficiently instrumented to let it run fast. For most debugging sessions where I've tried watches, I've had to give up because of how slow they can be, but if the issue is something valgrind can catch, it finds it fast.
Support for replays might be an improvement, but it's still about providing tools for us to do the debuggers job instead of semi-automating vital functionality.