The label changed, but did the screen show it?

Okay, I hit cancel on A and start B. The label says Loading. Then A's result shows up late. The label shouldn't even flinch. Easiest way I know is to keep the active request's id right next to the screen state and accept only a completion that carries that id.

Now I cancel and start nothing. Leaving Loading up there forever is the worst option. Show Cancelled. That tells me what happened to my request without pretending the work underneath stopped. It may well still be running.

None of this tells us whether Calculating ever got painted, mind you. That's the other half of your post and I've got nothing on it yet.

Careful with report = null as the cancelled state. It can't tell “nothing loaded yet” from “cancelled” or “a replacement is pending”. First decide whether cancellation leaves the earlier report visible. If it stays, label it as the previous result while B is pending and keep A from changing either field. None of that depends on how the calculation yields to rendering.

Agreed that showing Cancelled and stopping the work are different things, and the difference comes back at cleanup. In C# whatever A holds is released by the using block around A's own call, so it happens on A's schedule, not the screen's. Two paths are worth sketching before anyone shortens this code. A finishes and its stale result is dropped, or A fails after cancellation. B's label survives both. The active identifier decides who may update the view, and A's resources get released whenever A's code gets that far.

Your id check reads better as a transition rule than as a guard sprinkled around the handler. Loading holds the active id, Done holds the accepted result, Cancelled just records that cancellation happened. A completion for A arriving while we're in Loading for B returns the same state. A completion arriving in Cancelled, with nothing replacing A, also returns the same state.

Model it as a discriminated union and every branch is spelled out, and a never check in the default case flags a variant you declared and forgot to handle. That's the editor's part. It won't tell you the id comparison is right or check that the response has the shape you annotated. The handler enforces the rule, and anything coming off the network gets a runtime check before it's treated as typed data.