I just realized that my implementation is actually wrong because shield() needs to return a Task. Therefore it fails in some scenarios. Will update as soon as I found a fix.

Now it should work correctly! Took me a while to figure it out but now it actually looks like a fairly small change to "task.py".
By subclassing Task in shield.py I can prevent the "shield" attribute from taking additional resources unless you use shield().

Only CPython difference in the tests is the cancellation order of wait_for.

I put shield() back into funcs.py and changed the way Task.shield is assigned to the same way Task.waiting is done.
Will have to be implemented in _uasyncio Task too

Testcases updated and extended. The result is now the same as Cpython even in wait_for cases if the fix in #5931 is applied.

Thanks for updating this. It is quite clean although it still requires an additional entry in the Task object when shielding is used. This is not a show-stopper but does mean the C implementation (see moduasyncio.c) will be much more complex because it has to manage allocation of extra memory to hold this shield entry when it is assigned to.

It would be good to look for an alternative implementation of shield that did not need any modifications to the existing core code (but I'm not asking you to do that!).

With #6667, wait-for can be fixed without shield, but IMO shield is still useful in its own right.

Thanks for taking a look at this and wait_for!
I thought it'd be a small and non-complex addition to moduasyncio.c, similar to Task.waiting, which gets lazily initialized too:

STATIC mp_obj_t task_make_new(const mp_obj_type_t *type, size_t n_args, size_t n_kw, const mp_obj_t *args) {
[...]
    self->waiting = mp_const_none;

I thought it'd be a small and non-complex addition to moduasyncio.c, similar to Task.waiting, which gets lazily initialized too:

Except that adding a new entry to mp_obj_task_t would make it 9 words big, which now takes up 3 GC blocks instead of 2 (there are 4 words per GC block). So the lazy initialisation would need to do something like make task->waiting into a tuple of 2 elements, on for the original waiting value and another for the shield value (I did something similar to this in a very early version but it was not needed in the end).

This needs a different solution that doesn't require adding a member to the Task object.