Cool. After reading your README, the "post-part" hook is the most interesting part for me. Chunk-level hooks make it easier to plug into things like rclone or other workflows. As you mentioned, the single .rapel-state.json file tracks all chunk metadata. Does that state also pin the origin file identity while resuming, so it can detect if the remote file changed between sessions?

Is this like a modern GetRight?

GetRight is possibly the piece of software that planted the seed of fascination with computers and software in my head at a young age. It blew my mind that someone had made an app that could fix Internet Explorer dropping downloads mid-way through on my dial-up connection if my Nanna sent a fax to my Mum whilst I was on the PC.

A little bit of a nit - when tracking progress you can ditch the mutex by using atomic integers for the download progress. Instead of using locks, your test for a chunk being done becomes something like "downloaded == chunk_size".

You also never call UpdateChunkProgress, FYI! The code is a little confusing to read because of that dead variable, at first I thought that chunks are never resumed. ProgressTracker and State/ChunkInfo do similar things, if I were in your shoes I'd make it so that there's clear ownership over where progress is actually tracked.

...I'd probably move State to be saved on the _start_ of the download, have it solely be responsible for tracking the arguments that the download was called with. Rename it to DownloadArguments, delete all the runtime state tracking, as it's already inferred by the downloader on start.