I haven't gone through all of sections 3.1 and 3.2 yet, but it seems like 3.1 starts off on the wrong foot. It states that "the current RISC-V spec states that vsie.STIE is an alias of hie.VSTIE". I believe this (and the subsequent observations) are flawed for a combination of reasons.
First, the Priv spec says "When bit 6 of hideleg is zero, vsip.STIP and vsie.STIE are read-only zeros. Else, vsip.STIP and vsie.STIE are aliases of hip.VSTIP and hie.VSTIE." Not quite the same as vsie.STIE and hie.VSTIE always being aliases of each other. This will matter down below.
Second, note that the Priv spec says, regarding vsie.STIE, that:
In other words, vsie.STIE substitutes for sie.STIE when (and only when) V=1.
And sie.STIE is not an alias or anything else of hie.VSTIE. The spec says that "the nonzero bits in sie and hie are always mutually exclusive".
Thirdly, note that hie.VSTIE is the enable for hip.VSTIP and hip.VSTIP "is the logical-OR of hvip.VSTIP and any other platform-specific timer interrupt signal directed to VS-level". A vstimecmp interrupt would fall in that latter category.
Fourthly, when hideleg bit 6 is zero, then hip.VSTIP=1 is directed to be serviced by HS-mode. But when hideleg bit 6 is one, then hip.VSTIP=1 is directed to be serviced by VS-mode - and then (and only then) is vsip.STIP an alias of hip.VSTIP (and vsie.STIE an alias of hie.VSTIE).
So, in this latter case, since a vstimecmp interrupt factors into hip.VSTIP, it then also factors into vsip.STIP. And when the vstimecmp interrupt is recognized, it is taken in VS-mode and not in HS-mode (i.e. not into the hypervisor) due to hideleg.
Conversely, if hideleg directs the interrupt to the hypervisor, then vsie/vsip.STIP are not aliases of hie/hip.VSTIP. And hence clearing of hie.VSTIE does not not affect vsie.STIE (vsie.STIE, in fact, is read-only zeros).
So it seems like the stated problem case in section 3.1 cannot arise.