If you want a response, a support ticket is the way to get one.
If you are in the Beta program, firmware 220.127.116.11 was just released, and one of the issues addresses was the switching between modes. I was just trying to reproduce a “what is this?” video, and I was in a bathroom with no windows to get a dark setting, and while I was making the recording, the camera switched back to daylight mode. So they still have some kinks to work out IMO.
Unfortunately, the v2 cameras no longer have a light detector above the lense. So the mode switching is based on what the camera sees.
My guess is that the firmware added more hysteresis*. But it’s not as simple of a problem as it is for things like temperature that have a much lower rate of change.
I don’t think a minimum time between mode change would work well in general. Example. Garage with no light at night. You go to garage to get something from your car. You turn on the light, get what you needed, and turn off the light 30 seconds later. Do you really want the camera to be blind for the next 4 1/2 minutes?
I do think a short delay where the new state is stable for a minimum amount of time (maybe 5-10 seconds) may be a good thing, and perhaps the delay should be longer when changing from NV (Night Vision) to DL (Daylight) than changing from DL to NV. The NV at leas gives a usable image in DL, the opposite is not true.
In control systems, hysteresis can be used to filter signals so that the output reacts less rapidly than it otherwise would, by taking recent history into account. For example, a thermostat controlling a heater may switch the heater on when the temperature drops below A, but not turn it off until the temperature rises above B. (For instance, if one wishes to maintain a temperature of 20 °C then one might set the thermostat to turn the heater on when the temperature drops to below 18 °C and off when the temperature exceeds 22 °C).