I wouldn't personally say that threads make control flow easier to follow: we might gain a little by disentangling separate activities into threads, but we lose a lot when these get interleaved in arbitrary, non-deterministic ways.
Threads' contexts should be independent from each other. If reading your stack trace relies on the state of other threads, you've got a very brittle design.
What is lost is the history of the state the current thread is working with, but the state should be fully encapsulated within the thread, except in the case of large shared read-only input buffers that are being processed in parallel. But those latter buffers aren't hidden from the current thread nor its debugging. Debug information can also be logged on state objects to show its provenance.
Sure. The trick is that the thread design does not ENFORCE that, threads as an abstraction involve shared memory.
> If reading your stack trace relies on the state of other threads, you've got a very brittle design.
Or a bug. And a bug or a brittle design is exactly when you need a debugger the most, right?
I mean, when a program panics, you get a stacktrace from (a consistent snapshot of) all the threads, so what's the problem?
Similar to having a snapshot of network traffic vs a recording of network traffic.