I²C has got an acknowledge bit and a stop condition. I'm making an operational assumption that you are asking about those. Please correct me if I'm wrong.
(I²C doesn't have a stop bit.)

But this raises the question: should an ISR wait on the STOP bit? If so, for how long? Is there anything in the spec about this?

The I²C specification doesn't cover the timeout. In theory, the slave must wait indefinitely. Likewise, the master shall wait indefinitely when the slave does clock stretching.

You could introduce a timeout in the slave device. The next layer of question revolve around what to do afterwards. If the slave had timed out, that means that communication is corrupt. How to you signal that back to the master controller? Do you try to recover? Do you try to shut down the entire system gracefully?

... flaky combinations of hardware and clocks... , so I am facing a redesign that assumes STOP bits to be unreliable (luckily I don't try to do variable byte counts).

I've been in a similar situation. Get the hardware fixed. You have to have stop condition in the I²C.

I²C has got an acknowledge bit and a stop condition. I'm making an operational assumption that you are asking about those. Please correct me if I'm wrong.
(I²C doesn't have a stop bit.)

But this raises the question: should an ISR wait on the STOP bit? If so, for how long? Is there anything in the spec about this?

The I²C specification doesn't cover any timeouts. In theory, the slave shall wait indefinitely. Likewise, the master shall wait indefinitely when the slave does clock stretching.

You could introduce a timeout in the slave device. However, you'd have to address the next layer of questions about the overall handling of the timeout. If the slave had timed out, that means that communication got corrupt. How will you signal that kind of exception back to the master controller? Do you try to recover? Do you try to shut down the entire system gracefully?

... flaky combinations of hardware and clocks... , so I am facing a redesign that assumes STOP bits to be unreliable (luckily I don't try to do variable byte counts).

I've been in a similar situation. Get the hardware fixed. You have to have stop condition in the I²C.

I²C has got an acknowledge bit and a stop condition. I'm making an operational assumption that you are asking about those. Please correct me if I'm wrong.
(I²C doesn't have a stop bit.)

But this raises the question: should an ISR wait on the STOP bit? If so, for how long? Is there anything in the spec about this?

The I²C specification doesn't cover the timeout. In theory, the slave must wait indefinitely. Likewise, the master shall wait indefinitely when the slave does clock stretching.

You could introduce a timeout in the slave device. The next layer of question revolve around what to do afterwards. If the slave had timed out, that means that communication is corrupt. How to you signal that back to the master controller? Do you try to recover? Do you try to shut down the entire system gracefully?

... flaky combinations of hardware and clocks... , so I am facing a redesign that assumes STOP bits to be unreliable (luckily I don't try to do variable byte counts).

I've been in a similar situation. Get the hardware fixed. You have to have stop bit in the I²C.

I²C has got an acknowledge bit and a stop condition. I'm making an operational assumption that you are asking about those. Please correct me if I'm wrong.
(I²C doesn't have a stop bit.)

But this raises the question: should an ISR wait on the STOP bit? If so, for how long? Is there anything in the spec about this?

The I²C specification doesn't cover the timeout. In theory, the slave must wait indefinitely. Likewise, the master shall wait indefinitely when the slave does clock stretching.

You could introduce a timeout in the slave device. The next layer of question revolve around what to do afterwards. If the slave had timed out, that means that communication is corrupt. How to you signal that back to the master controller? Do you try to recover? Do you try to shut down the entire system gracefully?

... flaky combinations of hardware and clocks... , so I am facing a redesign that assumes STOP bits to be unreliable (luckily I don't try to do variable byte counts).

I've been in a similar situation. Get the hardware fixed. You have to have stop condition in the I²C.