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, and it doesn't pretend the work underneath actually stopped (it may not have).

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. Let's follow the scope on the C# side. A using block disposes its resource when control leaves, exceptions included, and await using does the same for asynchronous cleanup. Neither one runs because the screen now says Cancelled. 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. It says nothing about when A's resources get released.

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, it won't check that the response has the shape you annotated, and it certainly won't get a label painted. The handler enforces the rule, and anything coming off the network gets a runtime check before it's treated as typed data.