dotnet-api-docs | NET API reference documentation (NET 5+, NET Core, NET Framework) | DevOps library

Is this true? Am I missing something?

I believe your reading of the source code is correct. But you shouldn't rely on this behavior unless it's documented. My guess is that the documentation simply hasn't kept up with the implementation, but you can open an issue here to get the docs updated.

.NET Core has lots of little enhancements like this that you might hesitate to make to .NET Framework for backwards-compatibility reasons.

When asked in the negative form like that the answer is, i think, pretty clear - there is no guarantee that the second half will be executed on a different thread to the first half. As you speculate, the original thread might well be the lucky next-to-be-picked available thread, when the continuation is up for executing.

Also important to note is that it's the context, not necessarily the thread, that is restored. In the case of a Windows message loop (e.g. WinForms UI thread), it is the UI thread running the message loop that picks up and executes the continuation, hence with ConfigureAwait(true), the same thread is guaranteed. With other SynchronizationContexts, though, there might be no particular reason to require or even prefer the original thread, as long as whatever is considered by them to be "context" is restored; e.g. HttpContext.Current [, identity, culture] in ASP.NET.

There is also an at-least theoretical chance that HeavyIo() completes synchronously, in which case there is no context-switching anyway, and the second half will simply continue on the same thread as the first. I can only assume from your choice of naming ("heavy") that you're implying this won't be an option.