i2c clock stretching issues?

Clock stretching can happen all the time. If the clock doesn't go high when the master releases it, then the master won't (and cannot) continue in any case.

However, if you look closer, teh clock IS stretched at (or rather after) the 9th fallign edge. In your diagram, it is shown after the 10th falling edge :)

After all, clock stretching makes only sense if you do it before you send an ACK - else you have to ack soemthing (usually yor presence) if you do not really know whether you're ready and willing to answer.
There's no othe rway to do this, since you only know after the 8th data bit whetehr you're addressed andasked to send something. And you must decivde before the next clock cycle whether to ACK or NACK this request. Stretching the clock after you already ACKed makes no sense.

Also, on MSP430, the interrupt of course comes when you are addressed/got the byte and not after you have acked the request/data. After all, the byte is complete when you received the 8th bit, and not after you have ACKed that you received it.

I think, this diagram is just an example of clock stretching (and a bad one) and not a 'here it must be or never' rule.

If you have problems with your particular master, you can go differently: If you get a START condition, stuff somethign into TXBUF, and when the following request is indeed a read request to you, there will be no clock stretching at all, as TXBUF is already filled with data to send. You will still get a TXIFG, since TXBUG will be emptied as soon as the data byte is being sent, and you are asked to either put another dollar in or, well, you cannot stop a transmit transaction,a s you cannot set a NACK if you're sthe sender. Even if you have nothing more to say, you'll have to put dummy bytes into TXBUF until teh master stops by itself - or the MSP will stretch the clock until you do so.

I know it makes no sense to put the clock stretching after an ack bit. However, the example of the bad one is from philips i2c specification 3.0,  and there are some MCUs put the clock stretching at the same position, such as Renesas MCUs. If the MSP430 (i2c master) can detect clock stretching at any position, there will be no compatibility issues.