osFlagsNoClear option for osThreadFlagsWait is not correct in CMSIS-RTOS2

CubeMX gives possibility use freeRTOS in the pfoject. Actually it is port over freeRTOS named as CMSIS-RTOS2.
I suspect that initially Thread Flags functions (like osThreadFlagsWait ) didn’t use osFlagsNoClear option. This option and osThreadFlagsClear() function were added later, but this work was made incorrectly.

  1. After osThreadFlagsWait() completition TCB->ucNotifyState become taskNOT_WAITING_NOTIFICATION independently of osFlagsNoClear option is set or not. However it must be taskNOTIFICATION_RECEIVED if osFlagsNoClear option is set, otherwise thread is blocked after next osThreadFlagsWait() calling inspite of flag itself is not cleared.
    Inside of osThreadFlagsWait() it should be checked before exit if some thread flags are not cleared and must be assigned taskNOTIFICATION_RECEIVED to ucNotifyState
  2. osThreadFlagsClear() is unsafe. I need use
      // must be in critical section because the different bit (bit0)
      // is manipulated from ISR
      osThreadFlagsClear(2); // unsafe!!! can be cause of bit0 clearing 

because of the next code inside of osThreadFlagsClear()

if (xTaskNotifyAndQuery (hTask, 0, eNoAction, &cflags) == pdPASS) {
  rflags = cflags;
  cflags &= ~flags;

  if (xTaskNotify (hTask, cflags, eSetValueWithOverwrite) != pdPASS) {
    rflags = (uint32_t)osError;

Try to realize what happens if after

if (xTaskNotifyAndQuery (hTask, 0, eNoAction, &cflags) == pdPASS) {

come interrupt with osThreadFlagsSet() function. Right, new set flag will be cleared!
Flag clearing must be added directly in xTaskGenericNotify() with eAction parameter.

I recommend reporting this to ST if it is an issue in the CMSIS RTOS code.