My recommendation is to always end every transaction with each device with a stop sequence. You will have a much greater chance of success in talking to various types of alternate devices that you try attach in the future.
I have specifically seen devices that behave badly when there is a missing stop at the end of the transaction.
As a matter of fact there was work I did, some years back, designing some slave devices into FPGA type parts. I found it essential to decode the stop condition and use that to reset the slave's transaction state machine. The main reason for this is that strange things can happen on the bus, things that the master side of the bus didn't even expect to happen. When an operation in progress gets corrupted by these "unexpected things" havoc can arise that takes some work to recover from. The best design strategy for devices is that they design to and utilize the stop sequence to produce the interface reset. When this strategy is followed the manufacturer of devices gets a lot less call for support and a happier batch of customers. Likewise the customer that is interfacing to devices will know about this and can simply provide for a "bus reset" of her/his I2C network that consists of a START -> STOP sequence pair. This can be utilized in the master side higher level driver software as part of a retry loop for when device communications has failed for one reason or another.
If you probe around on the web you can find certain app notes that describe various sorts of involved I2C "bus reset" schemes that try to recover devices that have hung due to unexpected events in the bus. Some of these include doing start - stop sequences with 9 or 27 clock cycles in between. Others have shown how to gate the power to the target device using a FET in the Vcc line to effect an "internal reset" in the slave device.
If everybody designed so as to simply reset off the stop sequence all the the bizarre I2C problems that can happen can be solved in a simple way without having to resort to schemes as discussed in these app notes. I have experienced a vast improvement in the robustness of newer I2C devices that I use in my own embedded design projects. This is such a relief as compared to LM75 temp sensors from 10-15 years ago that needed power gating of their Vcc pins to provide reliable operation OR some unnamed I2C 8-bit DAC/ADC that required extra clocks type recovery resets.
So based upon years of experience I want to recommend again that you not try to do this repeated start sequence / changed address scheme. Always follow the simplest sequence that get the job done for a specific I2C device. And make sure each transaction ends with a stop sequence and provide for a bus reset function that is a start-stop sequence pair.
I know that there are probably many readers here that are implementing I2C communications software that is designed on the assumption that devices will always just work. I would like to point out that there are a whole slew of mission critical embedded applications where this technique is unacceptable. It becomes necessary to detect every possible error in a transaction and then add another layer above this that includes retries and attempted bus reset recovery. And finally if critical behavior of the product depends upon the I2C channel that has failed take careful steps to shut down the device in an orderly and safe manner.