We can look at the ProduceRequest logic in their design doc - (https://docs.google.com/document/d/11Jqy_GjUGtdXJK94XGsEIK7C...)

  Check the sequence number map to determine if the PID is already present. 
    If it is not, check sequence number. 
      If it is 0, insert the PID, epoch, and sequence number into the PID mapping table and proceed to append the entries.
      If the sequence is not zero, return the InvalidSequenceNumber error code.
    If the PID is present in the mapping, check the epoch. 
      If the epoch is older than the current one, return InvalidProducerEpoch error code.
    If the epoch matches the current epoch, check the sequence number:
      If it matches the current sequence number, allow the append. 
      If the sequence number is older than the current sequence number, return DuplicateSequenceNumber. 
      If it is newer, return InvalidSequenceNumber.
    If the epoch is newer, check the sequence number.
      If it is 0, update the mapping and allow the append.
      If it is not 0, return InvalidSequenceNumber.

That's a pretty straightforward approach of enforcing idempotency; checking producer and sequence IDs and throwing them out if they aren't correctly ordered. The other big addition to the code base was cross-partition transactions, which, while pretty cool, is a far cry from "Exactly once delivery".