Why Storage "works"

The basic rundown is:
-Link is always considered in some state and he has an active function for each state. Let's call this currentProc. It is usually called every frame
-Playing the WW: Link's active function is set to procTactWait, where it forces Link into the playing animation and you can control the notes
-procTactWait when B is pressed uses the endDemoMode function to cancel the WW demo (HUD and black bars are removed just beforehand). endDemoMode checks in which real state Link is. If he is completely idle on the ground, it will use the changeWaitProc function to clear the current proc and you are no longer holding the WW
-Several checks are done to confirm if Link is busy or not and if endDemoMode can do an immediate proc transition or not. All relevant values reside in the daPy_lk_c class. On JP it can be found dynamically with the ptr at 0x803BD910
-The member at offset 0x494 (4 bytes) in the daPy_lk_c class stores some sort of Link ground state. The bit with value 32 is probably an isOnGround boolean. If isOnGround is true it will check a bunch of other parameters to figure out the correct state transition. As mentioned, completely idle on ground will end up using changeWaitProc
-If isOnGround is false, it does a bunch of more checks to see if it can still transition. A traditional fall is apparently deemed as impossible to transition to in this function, so the function exits and does nothing more at this point

-daPy_lk_c::execute, the master Link player function, also runs every frame since everything else branches off from here
-If the member with offset 0x304 (2 bytes) in the daPy_lk_c class is 5, the execute functions knows Link is in a demo and will not run checks if a state transition needs to happen. Let's call it linkDemoMode
-linkDemoMode is always properly cleared to 0 by the endDemoMode chain, thus firing the transition checks up again

-Nintendo relied on the fact, that if a busy state is present, that the state transition checks invoked by execute will pick this up and actually transition the state if endDemoMode bails out early
-One of these functions that check state transitions is daPy_lk_c::changeAutoJumpProc()
-If isOnGround (0x494) is true, this function exits early
-Nintendo expected this function to run with isOnGround == false, since it just confirmed with endDemoMode that it is false
-If that's the case, changeAutoJumpProc() will start a procFall state transition. Which happens if you miss the storage frame (the mid air fall)

Conclusion:
Storage thus happens cause endDemoMode and the next changeAutoJumpProc() happens on 2 different frames. So if you cancel the WW while in a fall, then end the fall before changeAutoJumpProc() can execute (which is frame perfect), nothing happens by the sheer fact that no state transition is ever detected.

There is seemingly no case for that and the player loop is satisfied that the current state must be correct. So the current proc remains procTactWait, allowing the B press again. Which again goes through the entire chain, but since you are on the ground right away, it now works as it should. And sets the eventCancel flag again where there is no demo to pick it up with, so it remains 1 giving storage.

On an unrelated note, using the WW again for camera lock seems to work cause the event is started and cancelled simultaneously, so the endEventCamera function called by procTactWait wanting to cancel the WW will not detect yet that the event camera is even active and thus does nothing. But since you are on the ground, the state transitions to full gameplay control. Thus the event camera is activated right after and then never cancelled, but everything else is cancelled as it should.


What did HD do to fix it?
endDemoMode implements an extra check to force transition the state back to idle when Link is in "busy" mode during procTactWait, which avoids opening the 1 frame window. Dives are additionally patched with a constant ground check in procTactWait that immediately cancels the WW state if you start to fall.