The 6502's decode ROM takes an input which tells it when to start the next instruction. In the case of something like an
LDA #7F, it is obvious that once the output from the ALU has been latched in the destination register, the ROM may issue the signal to start the next instruction.
As for the conditional branches,
BMI and so on either take 2 or 3 cycles depending on whether the branch is taken or not. That makes sense: in the case that the branch is taken, the ALU needs to update the PC. And otherwise of course, the next instruction may start early. But how is this behaviour implemented?
I can imagine one way to do it would be to have all the relevant flags serve as inputs to the decode ROM. Then
BEQ and friends could be microprogrammed to work differently depending on which bits were set. But a look at the block diagram shows that's not how it works. And probably it would be a wasteful way to do it since so few instructions would need it.
Another way might be to send the branch offset and the low byte of the program counter to the ALU, and then conditionally write the addition/subtraction to the low byte of the program counter if the branch is taken (also taking care to handle the carry-out), or else issue the next instruction. But the datapaths on the block diagram do not show that the data really can move in this way.
And the block diagram, as far as I can see, also does not show that there is anything which takes the status flags as inputs. So I am confused about how this actually works!