Error handling nested interrupts in STM8 (not described in errata)

The STM8 family has a very useful opportunity to save energy when fast and time-critical processing is performed on interrupts, while low-priority tasks run in the background. To do this, use the AL bit in the GCR register and the WFI machine command. However, an underwater stone was discovered here that is not described in the current version of errata on crystal.

This problem was detected on the stm8l152c6t6 crystal installed on the STM8L-Discovery board.
In the main process, the TIM4 timer was initialized for interrupt operation. The interrupt handler for it is almost empty (well, except for the procedure for resetting the TIM_SR1_UIF bit in the TIM4-> SR1 register). Further, the main process allowed writing to the EEPROM by unlocking the MASS and initiating the byte writing procedure with the generation of the IRQ after it was completed. Then in the GCR register the AL bit was set and the WFI command was executed.
In the interrupt handler, upon completion of a write operation in the EEPROM, after reading the contents of the FLASH-> IAPSR, the priority of the executed code is reduced by the RIM command or the PUSH # val / POP CC combination. Those. within the EEPROM ISR, all other interrupts are enabled. And the following was discovered: if the EEPROM ISR was interrupted by another interrupt, then after returning from a nested interrupt, the EEPROM processing of the ISR stops (that is, the impression that the CPU core switches to the WFI state performed by the main process).
This error occurs only when the following conditions exist:

1. Before running WFI in the main process, the AL bit in the GCR register was set
2. The priority of EEPROM IRQ is left by default (i.e. the contents of the register ITC-> ISPR1 is 0xFF)

Possible workarounds:

1. In the main process, before executing the WFI instruction, clear the AL bit in the GCR. In this case, after each interruption, the main process will resume its execution, which does not have a very good impact on energy consumption.
2. Before lowering the priority inside the ISR EEPROM (i.e. before the RIM or PUSH # val / POP CC commands), also reset the AL bit in the GCR. Again, in this case, after the completion of the EEPROM ISR, the main process will continue its execution, which will not have a very good impact on energy consumption.
3. Change the priority of the EEPROM IRQ in the ITC-> ISPR1 register, for example, by writing the value 0b11110111 to it. What is most incomprehensible, after that, the RIM or PUSH # val / POP CC commands start working inside the EEPROM ISR (that is, after returning from the nested interrupt, the EEPROM processing of the ISR resumes).

Gentlemen, who have the desire / opportunity, try to reproduce this bug on other crystals of the STM8 / STM8L family. For if this bug is truly reproducible, then it is necessary to kick the STM in order to fix it or at least include it in the errata sheet.
')
Received an official response from the ST MCU Support Team:

SOLUTION PROPOSED BY SUPPORTER - 5/4/2017 15:52:59:
- Dear customer,

If you’re trying to complete the process, you’ll have to go ahead.

I recommend to use SW rather than using RIM in the interrupt routine.

Best regards,
ST MCU Support Team