This seems like a dotNet bug, where cancelation timer is ineffective during stream copy task. Does it make sense to submit an issue report about this?
Also, the timeout time is now only for when there is no network connectivity. User expectation is that the timeout time is for the entire process including both connected and non-connected times. We would need to update the documentation to make clear what the -TimeOutSec parameter does.

This seems like a dotNet bug, where cancelation timer is ineffective during stream copy task. Does it make sense to submit an issue report about this?

This works for whole CopyToAsync but it is not that we want since full download can take unpredictable time. We need only monitor every internal request to target service for hang - the CopyToAsync has internal cycle where ReadAsync() is used. It is just the ReadAsync hangs and we need reset the timer for every iteration in the cycle.

That you assumed it was a bug in the .Net Runtime is an interesting psychological experiment. :-) That was my assumption too, and I opened a discussion there a few days ago. Only the .Net team offers workarounds and doesn't agree that HttpClient.Timeout should apply to operations on streams it creates itself, even though it works with all its other operations.
You could share your expectations there too if you want.

We would need to update the documentation to make clear what the -TimeOutSec parameter does.

Both .Net and PowerShell docs should be updated for the Timeout parameter - that it applies to every request to target service and protects from too long (infinite) network operations.

IMO, this is not needed.
We should timeout just in the timespan specified by -Timeout, but what you are doing here is to refresh the timer after every 1 second.

In the case you say the Timeout must be longer than the expected time to fully load the file. This immediately indicates a lot of problems. For example, the time to fully load a file is unpredictable even if there are no problems, because this time is determined by many factors (client, server, network). In general, even the size of the file is unknown. Thus, neither the script developer nor the user can set a reasonable timeout value - it will be very long for the script to accurately execute. But such a protective timeout is already possible in Task Scheduler or CIs - it can be an hour or two.
If you look from HttpClient side then before uploading it performs sending request and receiving response, these two operations are performed with the same timeout, but these are instantaneous operations - here you need timeout of a minute or two, but not an hour or two.
If you look at it from the service side, any service closes the session when it loses contact with the client after a short time. With Kestrel, for example, this is 130 seconds by default. Usually it's faster (about a minute). This means that it doesn't make sense for the client to wait an hour or two. This also makes it clear that it makes sense to specify a timeout just for each request and response operation. That's exactly what this code does. We can explicitly specify in the documentation that if network connectivity is lost, cmdlet will crash after a given timeout.

This is the doc for -TimeoutSec:

Specifies how long the request can be pending before it times out. Enter a value in seconds. The default value, 0, specifies an indefinite time-out.

To an end user, it doesn't matter it's because of sending/receiving http request or downloading a file, when specifying -TimtoutSec, what the user wants is for Invoke-WebRequest/RestMethod to timeout if the operation cannot finish in X seconds. So, we need to make sure that's the case (maybe not accurately X seconds, but closely around that time).

I prefer to use the existing -TimeoutSec. However, even if we have a separate parameter just for downloading timeout, it's semantics should be "timeout if the downloading doesn't finish in X seconds". An end user doesn't need to know it didn't finish because of bad network speed, or because the network disconnected and then reconnected.

The Timeout did never work for download scenario in all PowerShell versions.. So we can not say "the user want" for the download operation. In IO operations timeout is always protection from pending (which is just in the documentation)

@JamesWTruher and @SeeminglyScience, can you please share your thoughts on this (summary captured in #18005 (comment))?
Mark the PR to be reviewed by cmdlet WG.

Why do you think it is important?
I follow HttpClient implementation. It activates timeout before starting an operation.
https://source.dot.net/#System.Net.Http/System/Net/Http/HttpClient.cs,185

It's not that important, and you can choose to not accept this suggestion.
But in the HttpClient.cs implementation, it's using await and thus you cannot start the timer after calling await base.SendAsync. So, they have to start the timer before calling SendAsync there.

Are you sure this exception will be thrown when the cancellation happens?
In my script test, I get an AggregateException that wraps a TaskCanceledException instead.

$s = [System.Threading.CancellationTokenSource]::new()
try {
    $t = [System.Threading.Tasks.Task]::Delay(100000, $s.Token); ## delay for 100 seconds
    $s.CancelAfter(2000);   ## cancel after 2 seconds
    $t.Wait()
} catch {
    $e = $_
}

PS:32> $e.Exception.InnerException.GetType()

IsPublic IsSerial Name                                     BaseType
-------- -------- ----                                     --------
True     True     AggregateException                       System.Exception

PS:33> $e.Exception.InnerException.InnerExceptions[0].GetType()

IsPublic IsSerial Name                                     BaseType
-------- -------- ----                                     --------
True     True     TaskCanceledException                    System.OperationCanceledException

No, there is no AggregateException. I guess because we use Wait(cts.Token) but in your example Wait().

Hmm, we could fall in race condition if timeout was raised while we are in the loop body. So I replaced Wait with another overload which checks cancelation token first. https://source.dot.net/#System.Private.CoreLib/src/libraries/System.Private.CoreLib/src/System/Threading/Tasks/Task.cs,2670

I don't see any problem with timeout being raised while in the loop body. Wait(millisecondsTimeout, cancellationToken) will call cancellationToken.ThrowIfCancellationRequested within InternalWait, after a quick SpinWait.

Actually, we can differentiate them. Just check if cancellationToken is cancelled. If Ctrl+c is pressed, that token will be cancelled, otherwise, it's the timeout. So, we should write out error only if the cancellation is caused by the timeout.

Yes, you are right, we can (cancellationToken vs cts). Fixed. Also renamed cts to timeoutCTS.