It will be working like forwardsDuration and backwardsDuration, except they're either both the same number or one of them is 0. Considering how the duration parameter has to be renamed to achieve that, a more pack-friendly compromisation would be adding a boolean to determine which sequence should be instant, or by checking the sign of delays, since they are already separated into forwards and backwards.

For example, if an animation has a duration of 20, forwardsDelay 10, and backwardsDelay -10, it will open for 1 second after waiting for 0.5 seconds when the variable goes from 0 to 1, and instantly move back after waiting for 0.5 seconds when the variable goes from 1 to 0.
A much simpler and less confusing method would be of course having booleans like forwardsInstant and backwardsInstant, but they don't beat the simplicity of just having forwards and backwards durations, which breaks packs.

I'm un-sure if I want to re-code the entire animation system to implement this. Tabling it for now, as I don't yet know how much pain it will be. I do know that I can't change the variable value, so I'd have to change the delay, but that has its own set of pain points and will add a legacy compat layer I'd rather not do. Would have prefered this being fleshed out during the duration/delay and forwardsStartSound reverseEndSound type talks when the animation system wasn't yet well-used.

So, I'm going to call this closed with the new inhibitor code in V19.10.0. With this, you can use a visibility variable combined with an inhibitor and two levers to get the result you wish. Exact sequences shall be left up to the pack author.