"File Slack" refers to the data between the last byte of the file and the end of the cluster. It usually contains whatever bit pattern the OS uses to represent unallocated memory.
"Drive Slack" refers to clusters that have been deallocated but not overwritten. It can also refer to unallocated space that no longer falls within a partition boundary.
"RAM Slack" -- I have never heard this term before. Googling this, all the resources I find seem to be quoting or deriving from a book titled "Cyber Forensics: A Field Manual For Collecting, Examining, and Preserving Evidence of Computer Crimes" by Albert J. Marcella, Jr. and Doug Menendez.
I read the chapter where the term is used. Even though it was copyrighted in 2010, it makes reference to the way DOS and Windows 95/98 did things. That hasn't been relevant for over a decade. I could be reading it out of context though. Either way, this book appears to be the source of the term.
Windows stores data on the disk in clusters. A cluster usually contains 8 sectors of 512 bytes each, so 4096 bytes or 4kiB.
This is correct in the case of legacy drives and 4K "advanced format" drives. The sector size is truly 4KB on 4K "native" drives, so there is a 1:1 correlation between sectors and clusters for those drives.
Large files get split over multiple clusters, when the remainder of a file does not fill an entire cluster, this remaining unused space at the end of the cluster is called "file slack".
Also correct.
Windows always writes 512 byte blocks at once, so the first only partially used sector must get filled up before being written to disk.
This is incorrect. Windows does not write in blocks; only clusters. It will write data at any arbitrary size, but they will be in multiples of the cluster size (usually 4KB). The only time Windows cares about sectors/blocks is when an LBA address must be calculated. The low-level disk driver does this, not the filesystem driver. It's actually very inefficient to do reads/writes in 512-byte chunks. It works against the drive's internal hardware caches. Doing a dd in Linux with a 512-byte blocksize will confirm this. It's an order of magnitude slower on both reads and writes.
For whatever reason, Windows decides to pick a random sequence from RAM to fill this sector.
Also incorrect. Windows will write whatever is in the buffer. Almost every application (including the filesystem driver) allocates fresh memory from the heap when writing to the output buffer. When an application allocates memory, it does so in pages, which are (guess what!) 4KB in size. Unallocated memory is usually represented by a repeating bit pattern (not 00 or FF), so that is what will be written to the end of the cluster if it's not full. In cases where the application's output buffer is a modified copy of its input buffer, the slack will contain whatever data the input buffer had in it.
The remaining unused sectors in the partially used cluster remain unchanged and keep the bytes they had before, which can be parts of a previously deleted file in this location. It's called drive slack.
Also incorrect. Windows will always do a full-cluster commit even if there's only 1 byte of changed data. It is true that deallocated clusters have whatever data was in them before. Windows does not bother with zeroing out deallocated clusters. But none of this takes place at the sector level.
4KB is a magic number. Memory pages are 4KB. I/O buffers are 4KB. Sectors are 4KB now. Even the drive's hardware is optimized for I/O requests that are 4KB (or some multiple thereof).
All modern operating systems work this way (Windows, Linux, and OS X). The only exceptions to the rules above are applications that have the disk open for raw access. They completely bypass the operating system's API calls for doing writes. You only see this with low-level recovery and forensic tools because such applications do not benefit from all of the optimizations you get with buffered I/O.