The focused target can be impacted by the following case:

• the debugger is paused (can be in a worker, an oop-frame, main context frame)
• the user "navigated" to a different frame using the cd command
• the user "navigated" to a different frame using the frame picker (in Browser Toolbox)

To reflect what has been said during the last fission meeting.
I don't think this is a top priority for now.

Nonetheless, you are highlighting the fact that we have multiple, very different ways to target one specific context (which can be a worker, or a frame). Each case you mentioned is actually using an extremelly different codepath.

• frame picker
  When you select a frame, the context of all the tools are switched to the selected frame.
  The client call BrowsingContextActor.switchFrame, which act as if we navigated to the iframe.
  This was a workaround in order to implement frame switching easily, 100% on the server side.
  The target actor (BrowsingContextActor) emits a window-destroyed event for the current document and a window-ready for the iframe document. Thanks to that, both client and server codebases act as if we navigated.
  The notion of "currently targeted frame" is maintained on the server side, via the docShell attribute on BrowsingContextActor:
  https://searchfox.org/mozilla-central/rev/4436573fa3d5c4311822090e188504c10c916c6f/devtools/server/actors/targets/browsing-context.js#1313-1328

• cd webconsole command
  This command you can type in the console allows to change the evaluation context of the console and only the console.
  You typicaly do cd(document.querySelector("iframe") to switch the console input evaluation context to this iframe.
  This only impacts the console input. Its autocompletion and where the Javascript pieces you wrote are evaluated, i.e. in the iframe's global JS object.
  It has no impact on other tools.
  The notion of "currently targeted frame" is maintained on the server side, via the evalWindow attribute on WebConsoleActor:
  https://searchfox.org/mozilla-central/rev/4436573fa3d5c4311822090e188504c10c916c6f/devtools/server/actors/webconsole/utils.js#579

• debugger pause scope
  This is a special behavior of the console input. Whenever the debugger is paused on a particular context. And this context can already be either the tab's document, any of its iframe, or a worker. The input will be evaluated into this context.
  Out of the three features described here, this is the only one having a client side implementation.
  The notion of "currently targeted frame" is maintained on the client side, via the a combinaison of multiple states within debugger's panel redux store.
  There is a notion of "currently selected thread":
  https://searchfox.org/mozilla-central/rev/4436573fa3d5c4311822090e188504c10c916c6f/devtools/client/debugger/src/reducers/pause.js#390-392
  Which then allows to retrieve the "list of frames for this given thread":
  https://searchfox.org/mozilla-central/rev/4436573fa3d5c4311822090e188504c10c916c6f/devtools/client/debugger/src/selectors/pause.js#16-36
  And this is exposed to other panels, like the console and the console input (aka JSTerm) via this method:
  https://searchfox.org/mozilla-central/rev/4436573fa3d5c4311822090e188504c10c916c6f/devtools/client/debugger/panel.js#120-143

This was a description of the current codebase.
Now as to what we should be doing:

• We should have a unified way of selecting a given target. The targets are: tab's documents, any of its iframes (remote or not), workers. But we have some others in the context of the browser toolbox: addons and processes.
• This should be managed on the client side.
• We may have more than one target actually selected at a time. We would most likely keep the "top level target", which may always be the top level tab's document target. And a "currently selected evaluation target", which would only impact JSTerm input and may be a bit of the debugger.

Here is a few outcomes of these two conclusions:

• We should pull out some logic that is currently managed into the debugger redux store. This would naturally go into fronts rather than one tool internal data. We shouldn't need to start the debugger in order to start selecting another target.
• We should convert the iframe picker and cd command to a client side logic.

This work will most likely depend on bug 1565263 for the frame picker.

Putting as P3 since the interaction with the debugger already works.
We'll have to check for the cd command when we start working on it (but for now, cd only changes the evaluation context, which is handled on the webconsoleActor with the evalWindow getter)