That API is for submitting a transaction to a shared daemon that will queue the transaction and process it later, so the "I2C busy" status cannot occur. You are probably correct about the possibilities of partial success, but the application I previously worked with did not handle that and did not have problems from lacking that handling. It also drove only very simple peripherals.

Defining a nice API is the first step towards solving simultaneous access. The API must be an interface to an implementation that can queue and serialize transactions from multiple clients. What I suggested is similar to the I2C module I once wrote for an embedded application that handled some I/O in interrupt handlers or with DMA but did nearly all processing in a cooperative multitasking loop. The "I2C daemon" was another function called as part of that loop and an interrupt handler for advancing an "in-progress" transaction.