Different syntax for forward and backward scp

1)First syntax difference:
From local to remote:
scp file.txt remoteuser@100.10.10.10:c:\users\remoteuser\desktop

• just folder at the end of destination and it will work, file.txt will be created on the remote in the desktop folder.

If from remote to local:
scp remoteuser@100.10.10.10:c:\users\remoteuser\desktop\file.txt c:\users\user\desktop\file.txt

• only with file.txt at the end it will work, not specifying a destination filename leads to an error, but program has been given the path and the name of a source file, couldn't it generate full filepath needed for the file transfering as in the first case?

Is it such by protocol and why so?

2)Second, perhaps bug:

• scp c:\users\user\desktop\file.txt remoteuser@100.10.10.10:c:\users\remoteuser\desktop, оr even
• scp "c:\users\user\desktop\file.txt" remoteuser@100.10.10.10:c:\users\remoteuser\desktop, or just
• scp desktop\file.txt remoteuser@100.10.10.10:c:\users\remoteuser\desktop - specifying relative or absolute local path leads to strange concatenation between local and remote path in scp's local path internal representation, hence leads to an error.
  Only
• scp file.txt remoteuser@100.10.10.10:c:\users\remoteuser\desktop works, with plain filename as a local source path, so that navigating through cd commands becomes the only option of successfull usage of scp forward syntax.

Should scp "c:\users\user\desktop\file.txt" be escaped in some more robust way that just quotes because of ":" and how, or is it an implementation-specific decision to work just with plain filename as a source in a forward from local to remote scp?

Start by reproducing the listed scp commands on Windows, comparing absolute and relative local paths with remote Windows paths. Trace how scp parses the two endpoints; done means the intended forward and backward forms have consistent, documented behavior and regression coverage.