It's not entirely "manually" checked in .NET, it is also sometimes "panic on cancel" in that the most common "manual" "check" in .NET is a simple `cancellationT

It's not entirely "manually" checked in .NET, it is also sometimes "panic on cancel" in that the most common "manual" "check" in .NET is a simple `cancellationToken.ThrowIfCancellationRequested()`. While it is great to implement high-level, intelligent cancellation, for the most part in .NET as long as you are passing the CancellationToken to enough low-level components you are increasingly more likely going to get a TaskCancelledException from your low-level components and maybe don't even need to wire high-level checks. (Depending on what your business logic is, and yes, the usefulness of unwinding effects at a high level such as carefully rolling back transactions or what not.) Also it's really interesting that the original F# approach to .NET Cancellation was to handle them automatically in async { } blocks, handling and for the most passing them automatically, and after a lot of usage patterns seen in the real world they decided that the overhead of all the automated checks wasn't worth it enough and the new in F# 10 task { } blocks follow the rest of .NET in preferring entirely manual CancellationTokens.