What should we add?

Any qubits that are idling within a control-flow block will be stripped from the block if routing runs on it. This is a side effect of how control-flow routing is done; we first expand the block to all physical qubits, recurse the router, then contract it back to non-idling qubits.

This can in many ways be considered a fair optimisation, especially for the control-flow operations currently implemented, since it reduces spurious data dependencies. However, it does change the semantics of the circuit in a way that is not entirely appropriate for routing to do, and it becomes more of a problem when explicit no-ops are given higher status as in #13767. For the upcoming box, removing the qubit dependency is a violation of the contract, since the data dependency is a part of the box semantics (certainly for some "verbatim"-like annotations).

There are two steps to this:

• make the routers contract to at least the physical qubits corresponding to incident virtual qubits that were originally incident, plus any additional physical qubits now touched by routing, such that the virtual-qubit dependencies on input and output are non-strict supersets of the pre-routing state.
• add a transpiler pass to relevant optimisation loops that performs legal contractions of control-flow operation bodies (probably both abstract and hardware-lowered optimisations).