• If you want maximum speed use multiple I2C peripherals, one for each device
• Otherwise, I think you ought to put in a gatekeeper task. Same way we did CAN last year. See https://electronics.stackexchange.com/questions/368015/multi-thread-i2c-synchronization

I would try to design for the case where you have 2 state estimation threads running in parallel (as seems to be done in some redundant configurations I was looking at), one for each IMU

They say in that post I linked, give it a pointer to a data buffer (presumably for the read data), but this obviously begs the question of "how does the calling task know that the buffer it passed has been filled". I suppose you could ship a semaphore along with it?
so you would have like

{
uint32_t cmd_len
uint8_t I2C_addr
struct I2Ctransaction *commands
uint32_t data_len
uint8_t *data
SemaphoreHandle_t done
}

eh?

https://docs.google.com/document/d/12RiXJ1J8ImkTuui0jkFiIdUy7xML1SvxLy82ACC8qKg/edit?tab=t.0#heading=h.fmdwnyb5c0ih

update: board respin puts only 1 i2c device on each i2c bus, and each device has its own handler thread so there will be no multithreaded i2c conflicts. task scope decrease!! this module no longer needs to worry about multiple threads accessing the same bus