uWSGI lazy-apps with cheaper algorithm: undefined worker scaling behavior under load

I am tuning a uWSGI 2.0.x deployment that uses the cheaper algorithm to scale workers dynamically between a minimum and maximum count. I want to enable lazy-apps so each worker loads the application after forking, reducing shared memory and allowing the master to start before the app is loaded.

The uncertainty is how these two features interact. With lazy-apps, each newly spawned worker pays the full application load cost at fork time rather than sharing a preloaded copy. It is unclear to me whether the cheaper algorithm's spawn and retire decisions account for that per-worker startup latency, or whether rapid load fluctuations could cause workers to be spawned and killed faster than they can finish loading the app.

I also cannot tell from the documentation whether cheaper's idle-detection logic treats a worker that is still loading the application as busy or idle, which could lead to premature termination of half-initialized workers.

Is the interaction between lazy-apps and the cheaper algorithm formally defined anywhere in uWSGI's documented behavior? Should worker startup latency under lazy-apps influence how I set the cheaper step and idle limits? Is there a recommended way to observe worker spawn/retire decisions to confirm scaling stays within the configured cheaper range?