This is definitely an ambitious project, and I worry that you are biting off more than you can chew in doing so. (I've attempted my fair share of debugger projects in the past).
At a low level, one of the main problems is that Linux's kernel interfaces for debugging are just absolute trash. (I see you have multithreaded support mentioned as a future task item, and that's one of the areas where you discover just how bad it really is). And of course ptrace composes somewhat poorly with, well, anything else, so if you want to use perf_event or eBPF to help drive the low-level stuff, well, combining everything into a single event loop is just painful. (Oh, and the documentation for all of this stuff sucks.)
At the medium level, everything is hampered by the number of secret handshakes that go on between the compiler, the linker, the runtime loader, the debugger. And the chronic issue that, in the debugger, you have to be prepared for the possibility that everything is just catastrophically wrong: your stack might be garbage (or downright nonexistent), the thread-local storage register might be a garbage value, variables may have values that don't make sense. After all, you're resorting to a debugger when things don't work, and part of the reason why it might not be working is because you've accidentally corrupted everything.
And at the high level, there's the UI which, as someone who doesn't work on UI, I find terrifying in its own right.
Trying to solve not one of these issues, but all of them, at once, in a new project is ambitious. I'd personally prefer a lot more a project that only tried to tackle one slice of the stack, not all of it.
Yup, Linux is nowhere the Unix successor we deserved. I have started multiple systems projects in Linux and gave always given up due to how shoddy the foundations are. It seems like the kernel just copies whatever cool feature they find in Solaris, BSD, Plan 9 or even NT without paying any attention to their composability, while the user space people are just a clique trying to force their way on everyone (why is the loader part of libc again?).
There are a few things where Linux has been the innovator (eBPF comes to mind).
But process control is not one of them, and almost any other operating system manages to have a more sane interface. Personally, if I were writing a debugger, I think the OS with the sanest kernel interface is probably Fuchsia, partially because everything is handle-based and partially because pretty much every syscall takes in a handle to the process to operate on, so you can do things like manipulate memory maps of another process without driving yourself insane.
At a low level, one of the main problems is that Linux's kernel interfaces for debugging are just absolute trash. (I see you have multithreaded support mentioned as a future task item, and that's one of the areas where you discover just how bad it really is). And of course ptrace composes somewhat poorly with, well, anything else, so if you want to use perf_event or eBPF to help drive the low-level stuff, well, combining everything into a single event loop is just painful. (Oh, and the documentation for all of this stuff sucks.)
At the medium level, everything is hampered by the number of secret handshakes that go on between the compiler, the linker, the runtime loader, the debugger. And the chronic issue that, in the debugger, you have to be prepared for the possibility that everything is just catastrophically wrong: your stack might be garbage (or downright nonexistent), the thread-local storage register might be a garbage value, variables may have values that don't make sense. After all, you're resorting to a debugger when things don't work, and part of the reason why it might not be working is because you've accidentally corrupted everything.
And at the high level, there's the UI which, as someone who doesn't work on UI, I find terrifying in its own right.
Trying to solve not one of these issues, but all of them, at once, in a new project is ambitious. I'd personally prefer a lot more a project that only tried to tackle one slice of the stack, not all of it.