Fixed‑time‑step vs. variable‑time‑step: which better supports graceful cancellation in MonoGame?

The goal is to ensure that when a cancellation token is triggered, the game loop stops heavy update work promptly while still allowing rendering to finish or exit cleanly.

MonoGame's Game class exposes IsFixedTimeStep and TargetElapsedTime for a deterministic loop, but it does not automatically inject a CancellationToken into Update or Draw, leaving the developer to poll the token manually. It is unclear whether the fixed‑time‑step’s built‑in step capping or the variable‑time‑step’s manual accumulator provides a clearer, lower‑overhead path to respect cancellation without missing draw calls.

Does fixing the time step simplify timeout detection because each Update call is bounded by TargetElapsedTime, making it easier to check a CancellationToken at the start without risking missed frames?

Does a variable‑time‑step approach, where developers accumulate elapsed time and cap each step, provide lower latency cancellation but require more careful token polling to avoid corrupting state?

Which strategy yields fewer chances of a deadlock or indefinite block when the token is signaled during a long‑running update, while still allowing Draw to be called unless the game exits?