things about unexpected behaviour in MSC transfer flow

during the process of transfering daplink to a currently not supported usb device, I encountered an assert in usbd_msc.c, although I managed to fix it, I do not know if it is a real issue.
When MSC flow triggers "MSC_BS_DATA_IN_LAST_STALL", it first stall the in-endpoint, and then send a CSW to exact same in-endpoint. Then when host decides to clear the stall endpoint by "clear feature", the behaviour in device is to clear the stalled in-endpoint first and the re-sent previous CSW(in "USBD_ReqClrFeature_MSC").
The problem of this process is that there are two exact same CSW stored in USB TX FIFO which will eventually be flused out with an in-token thereafter, which actually cause some misbehaviours and assert on my device. But I also think that this duplicated CSW packets should cause problems on all devices.
I do not know why it is designed like this, hope someone who know better about msc.c can shed a light.

Start by tracing the MSC_BS_DATA_IN_LAST_STALL path in usbd_msc.c, then inspect USBD_ReqClrFeature_MSC and the handling of the in-endpoint stall and CSW. Reproduce the transfer flow if possible and determine whether the same CSW is queued twice; done means the behavior is explained and any confirmed defect has a regression test or documented resolution.

Written by the indexing model from the issue text.