Undocumented 10s reset time of Bootloader on unexpected I2C behaviour

[Rainstick]

I’m using a Raspberry Pi host to flash an STM32G030 via I2C.
The Raspberry Pi (all models except 5 and newer) have a known hardware bug in their I2C clock-stretching support.
See e.g. https://www.advamation.com/knowhow/raspberrypi/rpi-i2c-bug.html
The interaction between a Raspberry Pi and the STM32 Bootloader over I2C is thus erratic. It works most of the time (including full verify, erase and flash cycles), but around 10% of the time, it will fail on the first two commands sent. Since it is quite timing-sensitive, with the bug triggering if the STM32 responds within a specific time window, that might be a reason why commands like GET, GET_VERSION, and GET_ID seem to be affected more, but flashing (which is sent much more often) works.
 

Obviously there is little that can be done on the STM32 side. But I wish the AN4221 would document the followup behaviour of the Bootloader more clearly to help identify this issue.
Notably, the STM32 gets into an invalid state, in which it does not respond to any I2C command, and then resets after 10s and enters user code.

Please consider mentioning this behaviour in AN4221!

Thank you!

PS: I attached a recording made with PulseView of how it looks on the wire (both with and without the clock stretching bug of the Pis).
The 0x3E address is used in the user code, in between it will try to switch to the bootloader and back, 6 times successfully, 1 time unsuccessfully. A first GET_VERSION will trigger the bug, a second attempt will enter an invalid state. The 10s reset time is not recorded.