Linux – FTP upload & overwrite does NOT overwite, but creates [file.ext].# instead

First things first, setup separate Unix accounts for each user. Associate those accounts with the FTP server. Although really, you should use Secure FTP via SSH. With newer versions of OpenSSH, you can setup "SFTP-only" accounts that are Chrooted into that user's home directory. Bam! Now you have users securely logging into their own home directories with no visibility to the entire file system. Files are written using their own user/group permissions.

Then, you can setup FastCGI to run with individual user permissions. It looks complicated, but there is a tutorial available here: How to setup FastCGI with Individual Permissions

This is probably the best approach (albeit the most complex) if you are trying to setup shared hosting for various users, especially if they are "untrusted" users. In this way, no one will be able to use PHP scripts to mess up each other's files.

If you can live with the fact that a user can maliciously access another user's files, you can continue to let FastCGI run as www-data. Then, when you setup each user's home directory, make the files owned by www-data GROUP. Then, set the switch bit in chmod (i.e. chmod 2770 instead of just 770). This will force newly created files to inherit the www-data group owner and allow FastCGI to read/write them.

Phew! That was long-winded. Let me know how it turns out by posting a comment here!

Your colleague is right, in the sense that October 1985's RFC 959 doesn't seem to provide a command specifically designed for permission changes. RFC 959 does provide specifications of commands to upload files (RFC 959 page 30 has the “STOR” command to store files), download files (page 30 has the “RETR” command to retrieve files), and optional extensions like MKD (make directory) and RMD (remove directory). The RFC notes, "It is the prerogative of a server-FTP process to invoke access" "controls." (However, from my reading of the RFC, I believe that the "access controls" being referred to are more about supporting the ability to log in with a username, and not intending to refer to the idea of using FTP to change the permissions of files.)

RFC 959 page 47 contains a list of the commands that are built into the FTP specification of RFC 959. For a while, I was wondering making an FTP server for a specific platform, and I've read through each of those commands. I've also glanced through IANA “FTP Commands and Extensions” registry, which is referred to by March 2010's RFC 5797. I don't recall any of those commands providing a way to be changing permissions, except one:

RFC 959 page 33 has the “SITE” command. (Some FTP clients have a local command called “QUOT” or “quote”, which ends up sending a SITE command to the FTP server.) Basically, the standard of the SITE command is that text is sent to the FTP server, and the FTP server decides what to do with it. Usage of this command can do things like change file permissions, search a site for files, or reboot the FTP server. In theory, sending the command “HELP SITE” will show details of some functionality provided through the site command. RFC 959 page 33 even specifies this:

“The nature of these services and the
specification of their syntax can be stated in a reply to
the HELP SITE command.”

The challenge to this theory is just that the “HELP SITE” command actually results in showing text from the FTP server, and incomplete documentation might not actually document every single possibility available.

Based on Jonathan Leffler's answer to knoti99's question about “chmod syntax in FTP”, we can see that classic “ncftp” program did use the “SITE CHMOD” command to implement ncftp's “chmod” command, and that this feature wasn't supported by all FTP servers.

One more side note as I complete the FTP portion of this answer: FTP is very sniffable. Basically, what I mean by that is that FTP performs actions using "clear text". If you use "packet sniffing" ("packet capturing") software like tcpdump or Wireshark, you can see what happens with FTP. If you try transferring a file which is a small text file, and see what network traffic happens, the results will likely be pretty easy to comprehend. Using such an approach, you could change permissions and see what commands the software is actually using. I know this may be a bit more time-consuming to set up, which is why this answer provided many easier-to-obtain details, but knowing about this process could be helpful if you start to wonder any other details about what happens during FTP communications.

(I've edited this answer to add a response to another part of the question.)

It was suggested to me that the client is likely executing a chmod via SSH i.e. setting the permissions after the fact.

I think that's a nice guess, although I don't think that's accurate when it comes to FTP. Actually, that guess is probably accurately describing the precise process that is used whenever the SFTP and SCP protocols are used. Since both of those protocols are based on SSH, the "chmod" command may be sent using the same SSH connection that is used as the rest of the encrypted connection. From my reading of those protocols, I do believe that this actually is exactly how file permissions typically get set when using SFTP (and SCP if that also supports setting the file permissions).

However, the way that this is typically handled with the FTP protocol is a quite different story, as I just described earlier. If you're using the FTP protocol, which is plaintext, then it is technically possible but rather unlikely that SSH is being used to follow up. (If software is capable enough to support SSH, then it generally also supports SFTP or SCP or both. As a result, support of the old FTP protocol is usually designed so that the complexity of encrypted communications won't be used as part of the process.)