the time it would take to write such a debugger would be trivial compared to all the time it would save debugging programs.
show variable contents dynamically
  if possible show the data in a way commensurate to its type -- number, string, type name, member values, etc.
  also the abliity to show a short history for that variable, and each history item links to that program state and can immediately list thinsg like:
    how many iterations ago of the current loop or parent loop etc. it was changed
    what the last AST path to its function was that it was changed
    how many stack contexts up it was changed

for step-mode show the code with current instruction highlighted, but do it better:
  for each new stack depth, make a new window showing the code portion for that function
  make sure the highlighted code is always in view, but with a minimum of scrolling.
     auto-scroll page-wise instead of line-wise
     make the windows as small as possible but as big as necessary for minimum scrolling
       a function with 5 lines gets a small window, but a function with a single loop that's 50 lines gets a tall window
       but still try to scrunch windows width-wise according to average/maximum/geometric average line length (maybe also taking into consideration what's in a loop or a condition and what isn't) so we can fit more windows on the screen
    when necessary, scroll so that the top of a loop is at the top of the window so that we don't continually page up and down for a single loop when we don't have to
  can slow it down to an arbitrary speed in lines / second
  tell it not to step through a given function, a given class, or a given module
  tell it not to step through anythin gthat's *not* in a list of given functions, classes and modules.
  tell it not to step through below a certain context frame level
  tell it not to step through below a certain context frame level but only relative to the current context frame level of specified functions/classes/modules
  tell it not to step through below a certain context frame level but only relative to the current context frame level of *not* specified functions/classes/modules

set breakpoints
pause program
step backward? <- with limited state information available

for modules not written in the language, provide assembly-level debugging, or c/c++ debugging if possible
  ideally any number of supported languages for any depth of nested externalization.

create macros to feed the program as user interaction by capturing user input

capture a network stream to use it over and over again?

emulate other cpu's, especially those that you wouldn't necessarily be able to run a sophisticated debugger on.

it must be hard in some cases to interpret the stack in a core dump to know where the frames begin and end.
some methods:
  disassemble the program itself
  look for dwords that match the location of a call command, for potential pushed ip 's
  if we've identified a frame then we know that every frame that with a return ip to that location storing the same value (the location being called) is of the same size
  we can help determine a frame's size by looking at push's before the call that it returns to, and also by looking at the sum of pop's - push's at the location that the call it returns to calls before the next ret command.
  by taking note of all the call locations in the program, we can try to sync up our frame delimiting (determine which values matching call locations are just coincidental) by finding the interpretation that seems to be the most coherents

create breakpoint hooks for certain variable values or combinations of variable values
  a string matches x (regex probably not necessary, but we'll see)
  a string contains substring x
  a given slice of a string matches x or contains substring x ?
  a name takes on a certain type
  a name changes type
  a dict item or list index takes on a certain type
  a dict item or list index changes type
  for a name, dict item or list index v, v > expr, v < expr, v != expr, v <= expr, v >= expr, v == expr, etc.
  and, or, not, and nested grouping when specifying hook conditions

automated unit testing features?
can define and remove asserts without having to add them to the source code

ability to list all objects in memory at the current point, with various modes of categorization
  ability to select an object and put breakpoint hooks on it
  modes of categorization:
    sort by time since last read
    sort by time since last write
    sort by time since last read or write
    sort by time since created
    by function, module or class that created it <- tree view
    by function, module or class that modified it last <- tree view
    by function, module or class that read it last <- tree view
    sort by name
    by how many contexts up its first detected reference currently resides in
    by type of object
    by namespace <- tree view
    by frequency of reads <- within an arbitrary window of time?
    by frequency of writes<- within an arbitrary window of time?
    by frequency of reads/writes<- within an arbitrary window of time?
    sorting methods should be able to be used in conjunction with each other and with the grouping mechanisms

• general notes:

  some of the examples above were written with python types in mind, but it's the general idea that counts.

  i'm guessing that some of the features would require extensions to the particular interpreter or compiler

shows the source code and shows curved arrows pointing all over the place to indicate the way the code traced through the code
and highlights sections that were used