If someone wants to look into it and is willing to tinker with the guts of the phone, the first thing is to see the state of the bus when the devices stop responding. I2C's "idle" level is high thanks to pull ups, the devices only drive the bus through an open drain.
Sometimes a device's state machine will go fubar (either because of a hardware bug or programing error) and will lock the bus down, basically making it impossible for anybody else to use it.
If this happens the next step is to disconnect/reset all other devices on the bus to make sure which one is screwing up (that's the difficulty with I2C, since the two lines can be driven by any master or slave you can never really know who's doing what when things go wrong).
An other thing to look for is the level of the line. Since there are many devices and pull ups on the wire it's not common to have messed up levels (0 is really 0.2 or 1 is really 0.8, if the pull up is too strong or too weak respectively). Depending on temperature and other factors that can lead certain interfaces to sample bad values.
And then well... you have to capture the transaction that causes the lock up and try to understand what goes wrong...
As a quick fix it might just be possible to force a reset of the bogus chip when a lockup is detected, that would prevent having to restart everything. There's usually a GPIO for that (if they wired it...).
I hope you have a good oscilloscope!
Quite frankly I can empathize with the dev not wanting to look into this bug, by the looks of it that's the kind of minor bug that'll take several days to track down and fix.