+1 for the pitch; seems like an improvement to me.
i am also at least in philosophical agreement that discarding the task handle implicitly should either only be allowed on Task<Void, Never> or that it should be banned from all tasks in favor of some more explicit fire-and-forget API. but i'm sympathetic to the concern that the volume of warnings a broader change would introduce may not be worth the developer annoyance.
on the matter of 'warnings as errors' that Jon brought up – i agree that introducing new warnings in non-major compiler version bumps is fine (and generally desirable). in this case though i wonder if either some specific new diagnostic should somehow supersede the existing 'no usage' one (as Raúl suggested) and include a diagnostic group, or if the existing warnings produced by the proposed changes should be added to a diagnostic group (they don't appear to have one today). this way the diagnostic behavior can be more directly controlled by teams using -warning-as-errors, and i think it fits with the spirit of the statement here that new warnings should be associated with a diagnostic group.