I'm going to offer a contrary opinion: I don't want the SlickEdit guys to spend a second on integrating Windows debugging in to SlickEdit. I use Visual Studio (since at least VS 2003) and find it to be a very powerful and useful debugger. I don't expect or want SlickEdit to be an IDE competing with Visual Studio.
I have no trouble switching back and forth, since I use SlickEdit for writing and understanding code, and VS for debugging. Two tasks, two tools. (I also have a dll, originally written by Gary Ash, that allows me to set VS breakpoints from SlickEdit, start the VS debugger from SlickEdit, and a few other things. Adding SlickEdit as an external tool on the VS Tools menu makes it simple to go from VS to the same file/line in SlickEdit.)
Rather than integrate a whole 'nother tool (a debugger) in to SlickEdit, I would prefer the SlickEdit team improve code visualization/navigation features. Call trees, #include hierarchies, better navigation with overloaded functions, better support for COM programming, etc.
What's next? Calls for a GUI composition capability in SlickEdit?