What should we add?

Instruction.condition is Qiskit's way of representing classical execution of instructions based on the values in specified classical registers. However, due to it's location as a property on Instruction (but outside params) has historically lead to it being overlooked, resulting in a handful of bugs where this condition information is either lost or not considered e.g. when evaluating instruction order (Some examples: #6475, #6810, #8553, #8040, #7950, #7247, #7006, #6994, #6583, #6192, #6016, #4727, #4672, #3164, #3215, #2667, #2571 .) Additionally, it is one of the pieces of mutable state that is currently preventing us from moving toward more lightweight Operation instances ( to resolve e.g. #3800, #5895, #7624, and #9372 ).

IfElseOp can currently represent a superset of what can be expressed with Instruction.condition and is more inline with how we expect to handle conditional and control flow operations going forward, so we should plan to deprecate Instruction.condition with equivalent usage of IfElseOp. This issue is to discuss and plan that process.

Deprecating Instruction.conditionwhile maintaining full backwards compatibility seems difficult (due to both a change in Operation type from Instruction to IfElseOp, and due to .condition being a property of the Instruction without context of the QuantumCircuit in which it is included). The following are two use cases to consider:

>>> qc = qk.QuantumCircuit(2,1)
>>> qc.h(0)
>>> qc.measure(0,0)
>>> qc.x(1).c_if(0, 0)

qc = qk.QuantumCircuit(1, 1)
qc.x(0)
qc.data[0][0].condition = (qc.clbits[0], 1)

Additionally, we should:
1)Updating existing visualization to inspect IfElseOp operations and, when possible, draw as an equivalent condition
2)Updating qiskit.assemble, similarly to visualization, to replace applicable IfElseOp s with their equivalent condition representation