Both the MC_LOCK_ON and the SSFS_LOCK_ON flags are generated as products of the manual switches and the global LSC.ENABLE switch, so they follow the fast unlock trigger and go to zero immediately when an unlock occurs; the SSFS_BOOST_ON flag, on the other hand, is based on the B4_SelectFilter SSFS switch, which we do no operate directly on: the cm command that we use for engaging the SSFS boost talks directly to the DSP. If I'm not mistaken, the B4_SelectFilter flag is 'attached' to the DSP object in Acl and it receives the information about the filter bank change from the DSP. It gets reset to 0 by the CARM_DARM_LOCK Metatron node, but this is probably too slow, also because any cm command is executed at an integer second.
As a test, I modified the logic in ISYS_Acl so that the new SSFS_BOOST_TRIG flag is the logical product of the old SSFS_BOOST_ON and SSFS_LOCK_ON, which is tied to the fast unlock trigger; a more clean solution would be to send the fast unlock trigger to the SSFS_Ctrl process, but the results should be identical (actually, with the 'ugly' solution we spare 1 sample in communication between processes). In the figure there is an example of unlock, and this effect now seems cured; I'll collect some more statistics over time to confirm it.