I don't, beyond what I said previously, which sounds like it doesn't fit your workflow very well.
I'm leaning towards a bug. If my suspicion is right that it has a roughly 2-second buffer (possibly to give the encoder some temporal space to work with?) with some variance in its actual length, and it discards that buffer when it stops instead of finishing it, then that might explain both of our quirks. The solution in that case would be to finish encoding the buffer instead of discarding it.
Regardless of what the mechanism is though, the requirement stays the same: Whatever happens in the real world before I click the stop button (or whatever it is that ends the recording) should appear in the file, and whatever happens in the real world after I click the button should not appear in the file. The tolerance is human imperceptibility (likely a small handful of frames). Whatever it takes to meet that requirement, do that.
Depending on how the startup works, it might require a special case to not create a short glitch-recording then, while otherwise keeping the above. For example, if everything starts enabled, and then some get disabled later according to the saved settings.
That would explain why I didn't see that problem. I'm set to always record, and use the enable to start and stop, and so I'm particular about not having it enabled unless I really do want to record. So it's naturally disabled when I'm changing stuff, and that works.
I completely agree on the usability though: a user action that does nothing with no explanation, is a problem.