During SCP a filesystem becomes full or the ulimits are breached and the server can no longer write to the destination file, the client continues to write until the end of the file and does not report the issue until it has finished sending the source. However if sftp is used it detects the issue and stops. Not a major issue, more of an annoyance as moving large files over a slow link does not provide a failure notification until several hours after the issue is produced. Tried with clients from 5.6 to 5.9p1.
The problem is there's no backchannel in the scp protocol other than the return code. Basically the sending scp says "write this here, this here and this over there" and the receiving scp gets to answer either "OK" or "not OK". The only thing the receiving scp could do in this case is to exit early with a non-zero return code. That would mean that in the case where more than one file is being copied, and only one has a problem (eg file size limit, permissions or whatever) right now all but the problem file will work. Changing it would cause it to work worse in those cases. Sorry, but there's nothing much that can be done with scp. sftp can do it because it's a much more structured protocol and the only suggestion I have is if this matters to you then use sftp.
Close all resolved bugs after 7.3p1 release