Thanks for agreeing :-) Like I said, I have no idea of the complexity
of such a change. However, it seems to me that you should be able to
implement a simple protcol-state-tracking logic for both CLI and MI
protocols, and simply simulate the --thread option for commands that
don't supply one. This way you could have both the backward compatible
stateful protocol, and have the -thread option to override it on the
individual commands.
This might be actually a reasonable thing. On one thing, not switching
the current thread might be good for CLI. On the other hand, I still believe
that --thread is ultimately better solution for MI. Then, it might be best to
make GDB not to switch threads (benefiting CLI and stateful MI), and
also accept --thread for the benefit of newer MI clients.
Now there's the catch that --thread is already implemented and is rather
straightforward, whereas I expect some corner cases in implementing thread
that does not change. I think we'll first get the non-stop mode working
with --thread, and then look into making current thread not change.
(For avoidance of doubt, "then" means "immediately after" not "someday").