What about Gradient Lag?

Yes, probably this would be the answer. I can show them the results directly in their HQ in Schaffhausen, as I live nearby and pass it on most of my rides 
What bothers me is, that other (much smaller) companies demonstrate, that it is technical possible. And if I pay the premium for a Garmin product, I have somehow the expectation, that basic functions like a near real-time gradient change is working. On the other hand, Hammerhead has still some other difficulties with the climber gradient, but current gradient is mostly pretty good and accurate.

On my Edge 800 there is one decimal (and perhaps 1 second delay). Before I noticed the lag on 1040 I thought that it was bad that they have changed to no decimal. It's a big difference between 1.5 and 2.5 which is both rounded to 2 (nearest even number). Then when I saw the lag I think it doesn't matter if they have decimals or not. But if they fix the lag it would be better with one decimal.

mcinner1 said:

Gradient lag is a consequence of the barometric chipset's altitude change indication being lagged up to 20 seconds.

I thought that you was just kind of joking, but I have read this thread again and already in page 3 @MikeF-Swiss posted statistics that shows that:
https://forums.garmin.com/sports-fitness/cycling/f/edge-1040-series/296993/what-about-gradient-lag/1445121#1445121

It's clearly not because of "smoothing" (as many have written as comments in DCR's review of 1040). And when I have tested this I'm sure that it isn't some kind of average for the last 10-15 seconds. On a small slope it was showing gradient 6% for a short time (with 15 seconds lag), if it should have been an average it would have been something like 2%, and not the max gradient for a short time.

I also noticed that the shown altitude was lagging, hard to say how much. If the altitude is lagging with 10+ seconds it's not possible to show gradient quicker than that. "Smoothing" or "This lag is a result of the amount of data inputs being processed.  This data is then fed into an algorithm to generate the grade readout." is just stories Garmin came up with in my opinion.

The question is really how can a modern high end bike computer have altitude lag of at least 10 seconds?
I also wonder how could they not notice this when testing 1040 while developing, and perhaps talk with the manufacturer of the barometer before production. How can there be more and more lag the newer a model is.

In my testing there is no altitude lag. During my recent climb I noticed that when on said climb, continuesly, it outperformed the previous mentioned Polar. The latter performs better on a rolling terrain, where 1040 has some serious lag/artifacts. But this my case. 

Are you sure about that? And what about gradient lag?

Also, perplexing that Garmin engineers saw how slow the 1030+ was with gradient lag - compared to the previous, (non plus-1030) version, and the previous, previous 1000 version …

Yet, they STILL went ahead with SAME hardware and unbearable lags in gradient - in the brand new, model 1040!

For the rolling terrain it was there. But it was one ride. Will observe it further in the coming weeks. 

Did anyone found solution to Climb PRO/ Power Guide LAG? I have some mixed experiences so I am leaning towards the theory that the course file could be the culprit. What is the source of yours? On the last ride I had mine from Strava and it looked like it was a plot from someones GPS as it was really erratic and messy. (something that suppose to be from DEM data I suppose?) 

This issue is FAR MORE annoying than the gradient lag per se. 

Very annoying. The thing is that sometimes looks to be on a different road. I had days where the different was more then 2 minutes . 

micro said:

This issue is FAR MORE annoying than the gradient lag per se.

I agree with that, but perhaps all is related.

I tested with Edge 800, 1040 and Fenix 7 today (with speedsensor for all 3, and saving data each second). The results are kind of strange I think.
Altitude was best on 1040 - when riding, when looking at the tour afterward there is a lag!

Result, best first
Altitude:
When riding: 1. 1040, 2. Fenix/800
When viewing: 1. 800, 2. Fenix, ...5 1040 (bad, appr. 15 secs lag, I think the same as the shown gradient during the ride)
Gradient:
When riding: 1. Fenix/800, .......5. 1040 (bad)

I think it's strange that the saved altitude is so much worse than the shown during the tour. Perhaps they have a very cumbersome algorithm for gradient that doesn't use altitude directly (the one that is shown). I think gradient/Climb PRO/ Power Guide lags are all related.

I don't know if the shown altitude when viewing it afterward is somehow adjusted and because of that seems to be lagging. BTW altitude for the 800 was almost perfect when viewing afterward, and not that good while riding.
I don't have altitude correction on any of my units.