I take your point for the sunrise case.
And any other time that exposure suddenly jumps.

Say, the sun peeks out and says "boo", from behind some clouds.
My partial thinking would work for sunset, ie where you would not get an over exposure following an AETTR in the nth frame.
Which is where the current AETTR functionality works best. When there is suddenly underexposure, AETTR has valid data to make an accurate decision on the first attempt at correcting the exposure settings. When there is suddenly overexposure, AETTR has to start
guessing how much to correct the exposure.
When I was asking
questions, this wasn't me being difficult, this was me giving you the opportunity to describe a strong user case for the new functionality. Why?
If this new functionality was to be implemented now, then next week, myself and other would be fielding questions such as, "Why does AETTR only work every now and then in my timelapses", "Why am I getting overexposure when using AETTR".
Personally, I am happy to answer these questions when the added functionality is a benefit to the community, but so far, this functionality would appear to only be useful during consistently darkening sunsets, and when using third party proprietary applications.
The risks are, it adds nothing over the current functionality when used correctly (worse from an SNR standpoint), is
yamlmo, and it will confuse some members of the community.
See the problem? It's not a case of just coding something because it's useful to one or few members. It has to fit within the guidelines of the development project, as a whole.
The good thing about open sources projects, is that you are free to develop things for yourself. Now, if you're not a developer, you don't have to drop everything, and start learning to code. Make small efforts here and there, and with community help, before you know it, you will be able to accomplish simple development tasks yourself, and you won't have to rely on others doing it for you, or grumpy old bastards like me.
