File naming conventions when sending file back and forth via email?

Not using version control is bad.

Depending on who I am working with, cloud-based[, version controlled] solutions to working collaboratively are not always an option.

You can use cloud-based solutions even when some collaborators are against them. All you need to do is: Download and email the cloud version to collaborators that refuse to use the cloud, and upload whatever they send back.

I come from a field where none of these answers are going to work. Remember, most scientists aren't computer scientists. As a grad student, sending professors arcane rules for naming conventions would probably just be ignored. Everyone has their own usual pattern, and even if they wanted to be helpful, might just forget when it comes time to save. What irks me is people that put spaces in filenames.

As much as I plan to improve this process if I ever run my own lab, here's what you have to do:

The first author (or author leading the publication, or the corresponding author, or someone picked to facilitate) runs the show.

1. When you send out a draft, state a date for when you'd like to receive comments by (two weeks is a good rule-of-thumb). Don't make your own edits in the meantime if you can help it.
2. When you send out a draft, put a date on it. When people start sending you comments, sometimes people will be kind and edit one that someone has already edited. IME, that doesn't always happen.
3. At the end of the time period, or once you've received everyone's comments, use Word's document merge tool.
4. Save with the new date, and start incorporating edits and responding to comments.
5. Rinse and repeat.

You will end up with a lot of files, with different dates. I keep the files from step #4 only, once you are confident in the merge. Frankly, space is cheap, and personally I find it easier to open paper-200303.docx to find an old comment than revision tools (for Word). When the paper is accepted, you can delete the old versions.

The key to modern version control such as git is knowing the parent documents of a document. You thus need to be able to reconstruct which the immediately previous version is.

So, ask them to mark their version with their new version number and name, at the least, but, ideally, add from which version they have constructed it (or multiple of these if this was a merge)

Thus, at the very least, OP could use -.-.txt.

So you could deduce that that rollingstones-4.2-PK.txt has been derived by PK from (probably) 4.1. As well as rollingstones-4.2-IR.txt has also probably 4.1 as parent, but modified independently by somebody else. When you merge versions with the same number, you can omit the author and just give it the following number, e.g. if rolling stones-4.3.txt is a merge of the previous ones.

If you can afford to and people are disciplined, it would help to mark the immediate predecessor, though: rollingstones-4.4-UM-from-4.3-PK.txt. This is a bit clunky and a poor imitation of modern VCS such as git, but it allows you to deduce the parent(s) of the present version which is all you ultimately need.

To facilitate that, ask people, directly on downloading the latest version, to duplicate it and modify its name immediately to reflect the parenthood of the downloaded version.