I'd argue here that it's not a problem of context storage, it's a problem of not ignoring cancellation in certain situations. Since context, for better or worse

I'd argue here that it's not a problem of context storage, it's a problem of not ignoring cancellation in certain situations. Since context, for better or worse, has two purposes, you may still want a lot of the request-scoped data for later operations after the initial timeout/deadline is done. And since context has a standardized bag of data, it's more future-proof to just keep using the context and its data rather than, say, extracting the data you know about today (like trace/span ids) and storing that for later use. Fortunately, following appropriate patterns here got a lot easier with 1.21 and the addition of `context.WithoutCancel`. If you're going to store a context for later use, since there's potentially e.g. tracing data you still want to keep, make sure you appropriately `context.WithoutCancel` to keep the data without keeping the original deadline.