When addressed as slave the I2C peripheral autonomously progresses into the new transaction, and if slave receiver then it can also completely finish the transaction without any action from the host driver. These transaction boundaries however are lost and worse yet the peripheral will use data from a previous transaction in a next transaction. The host driver meanwhile may be e.g. programming a master transaction, leading to all sorts of race conditions.

Examples:

1. Slave/master receive finishes but before driver can read all data and a new slave receive starts. There's still evidence of the second transaction due to AAS being set, but the boundary between them in the received data is lost, hence corrupting both transactions.

2. Slave/master transmit finishes (with NAK or AL) with data left in in fifo and next slave transmit starts before driver can act. The data in fifo is erronously transmitted as part of the second transaction.

3. Slave transaction starts while driver was programming a master transaction. Some settings or queued data intended for the master transaction may bleed over into the slave transaction. I've also seen state corruption occur.