Note: I wasn't talking about refactoring DSF or DSF-GDB themselves, but rather refactor CDT Core and UI to pick out utils and other common code into separate plugins. Ideally this would be a superficial refactoring - just moving a few classes around, maybe a few methods - but in practice I reckon it wouldn't be that simple, there be more in-depth refactoring required. (I haven't looked into it in detail) I might give it a go if I have the time.
As for refactoring DSF itself, I agree with Mark, things are actually pretty decent at the moment. Even if DSF doesn't work very well for implementing a new debugger integration (that isn't GDB nor MI-based), at least it still gives us DSF-GDB, which is quite nice.
Sure, there are a few things I'd like to see in DSF-GDB that make the handling of non-C/C++ languages better. But if I look at the big picture, it's actually in GDB itself that a lot of limitations come from, so that is a stress point much more than DSF-GDB is...
This does pose an interesting question: if someone where to write say, native LLDB integration for CDT, would they be better off using DSF as a base, or writing a debugger integration from scratch (just Platform Debug)...