There have been discussions a number of times about the problems with having multiple Debug I/O window and never knowing where the output is going to show up. I just ran into a similar problem that convinces me that this is a more general problem: tool-related actions, including commands, do not take into account the user's likely association of a window's tools with the editing and debugging activity in that particular window. I just tried using batch-search-forward, expecting this to be equivalent to clicking the ever-annoying green down arrow in the Search in Files tool showing in the front window, but instead, it jumped to the next occurrence of the search string showing in a different window's Search in Files tool, bringing that window forward. This would virtually never be the behavior I would want.
I think a lot of trouble could be saved if tools were "bound" to the windows in which they appear, and all commands and actions occurring in the editors or tools of that window act only on the corresponding tool in that window. A decision would have to be made about what to do if there were no such tool in that window -- I suppose in that case it would be reasonable to cycle back through the recent windows looking for one: probably 95% of the time that the current window does not contain the appropriate tool it would be the previous window's tool that would be the expected target of the activity.