Feature request described here: capture all scopes for async callbacks with correct values. Unfortunately, we cannot guarantee the correctness (in case you modified the variable between the async caller and async callback), since we can only capture the variable reference, not the value itself.

Consider this example:

Promise.resolve(0).then(i => {
        setTimeout(() => ++i, 200);
        
        var fullfill;
	var promise = new Promise(f => fullfill = f);
        setTiemout(fullfill.bind(null, i), 100);
        return promise;
}).then(i => {
	debugger;
	return i + 1;
});

If timeout for fullfill is less than for ++i (that's the case here), the value of "i" when resolving the promise would be 0. But when we pause on debugger statement, it could already be 1 due to ++i running in a timeout. That means capturing scope containing "i" will not help - the value would be already wrong.
If we swap the timeouts (100 vs 200), value could be correct, but we can't guarantee or even check that.

The situation is even worse if you consider objects, where three levels down the hierarchy everything could have changed many times.

The only correct solution here would be to capture all variable values together with the scope, but this would introduce huge performance penalties. The workaround is to use multiple variables (similar to j1, j2, j3 used in the second example) or console.log the values. Note that you can add conditional breakpoint with "console.log(i), false" expression to avoid code modifications if required.

Sorry, I wasn't clear enough. I don't expect that actual values are kept. All I want is that I can select a then callback in the call stack and can have a look at the variables. In other words, it should look like the then callbacks were executed like this:

lastThenCallback(innerThenCallback(firstThenCallback(initialValue)))

If you have a look at the attached screenshots, then you can see that it isn't possible to inspect any of the previous then callbacks while it is possible to inspect the variables of the previous setTimeout callbacks.

Does it make more sense now?

In this case we still need to capture variables on each then callback. Ability to inspect variables on async call frames was removed from current DevTools version in Chrome dev channel because it was confusing in some scenarios since we don't capture actual variables. We'd like to better support debugging on synchronous call frames and added some new experiments for it like resolving source mapped variables.

I don't understand this move. Async debugging is painful and I was really happy to see the async option in the debugger when it arrived. Without being able to inspect the variables (as in Canary), it is much less useful. Is there a technical reason why it cannot be fixed instead?