the feature seems reasonable to me. i don't have first hand experience with the issue it's primarily intended to address, but the new capabilities it offers seem probably best solved within the runtime itself. i do think it muddles the mental model for what it means to 'be cancelled' somewhat, but i'm not sure there's any way around that. unless, perhaps, we were to lean even more heavily into Trio's precedent and reify something like a 'cancel scope' that could be configured and used independently of a Task.
maybe now is not the right time for it, but it does seem like a more general means of 'configuring the cancellation properties of the ambient environment' may be appropriate at some point. i feel structured concurrency already suffers a bit from 'pyramid of doom' nesting, and if we need separate, nested functions for each possible configuration axis (cancel shields, timeouts, etc) that problem just seems like it will continue to grow.
i think exposing the test for the shield on UnsafeCurrentTask doesn't seem entirely consistent, because there's nothing really 'unsafe' about it. but, as long as there is a way for code to infer that this state is active (e.g. by repeatedly comparing Task.isCancelled and task.isCancelled), then exposing a more efficient and direct check may make sense.
as for the name: it seems okay to me. the metaphor isn't perfect, but it feels at least directionally appropriate. if i had to pick i might go for the somewhat more bland withTaskCancellationSuppressed.