this test seems invalid for now

I've had a very bad experience with this wait pattern, as it doesn't catch deadlocks: if the sender fails before actually sending a value, the receiver will wait forever. Similarly, if the receiver fails before retrieving the message, the sender will wait forever (if the channel is unbuffered). The @sync block will only "forward" that failure, if all tasks finished, which never happens in this case. That's why I've resorted to a timedwait.

IIRC, I saw some work on an eager version of @sync, Experimental.@sync maybe, but it's still experimental (i.e. discouraged for my use case). I couldn't find it quickly. #32677 describes some related ideas. I was looking into a custom @sync a la

tasks = ...
# new sync end:
@sync for t in tasks
    @async try
        wait(t)
    catch
        for t2 in tasks
            istaskdone(t2) || yieldto(t2, InterruptException())
        end
    end
end

but yieldto is, again, discouraged and people much more adept than me suggest this is a bad idea (golang/go#29011 (comment)).