My understanding is that the keyboard sends reports, of the current state of keys. It will not send a diff, it always sends a complete state. That makes things a lot simpler, because all the logic of how to update that state can reside in the keyboard firmware. Additionally, judging by how QMK appears to work, and what I saw in the KeyboardioFirmware code, the device itself can send a report (or queue a report, I don’t know, but it doesn’t matter much in this case) too.
For one-shots, this whole thing means that when a one-shot modifier is activated, the code will keep adding the modifier to the report, until it times out, or gets cancelled. Then it simply won’t add it anymore. This means that the modifier will appear held as long as one-shot is active, no interruptions. Same for sticky shift: the firmware will make sure the report has the modifier set.
Normal shift Just Works™, because as long as you keep pressing it, the firmware will set it in the report.
For shift-inverted, if it needs to send a code without shift pressed, it will clear shift from the report, add the code, send a report, and re-register shift if need be. For shift-needing codes, it will register shift, and the code, send a report, and un-register shift if need be. This may have some side effects, when you are holding other keys, because the report is not cleared inbetween, so the shift will appear interrupted to the host. But I expect that to be a rare case, and if it ever comes up, we’ll figure something out to make it less annoying. Worst case is an OS-side layout… in this case, that is considerably more reliable.