I've used one-time-link services sometimes, and posting the link to Slack causes Slack to make an HTTP fetch looking for metadata, which then invalidates the link.
Then, any automated system which sees the link cannot accidentally cause the file to be "downloaded" which would cause the link to be invalidated. They can see the link itself, but they don't have the password, therefore they can't download the content to scan it.
I have used onetimesecret.com a number of times in this way.
It's a very common and easy to anticipate issue, I'm surprised that there are any one-time-link services left that suffer from it.
But to answer your question, I uploaded a 100mb+ file to FireFox Send, copied the link, RDPd into another computer, kicked off the download, and then cancelled it midway through download. The link did expire after that.
So I guess they don't have an easy way of telling whether the download is successful or not. Maybe Mozilla's engineers can figure something out if the issue is raised.
Firefox might consider keying off the initial IP seen upon retrieval and extending the TTL of the object until the final byte has been retrieved.
There's probably enough complexity and possibility for abuse in allowing automated requests for files again (i.e. a button on the view page) or special logic for second attempts that the safest option is just to have the receiving party ask for the file again through whatever medium originally kicked off the request (an email, an IM, etc).
Firefox could do any number of things to make it easier on the user, but I expect them to take my security and privacy very seriously and to error on the side of those ideas rather than usability, so hopefully if they come out with something it's not at odds with those goals.
In an ideal world, partially-downloading the file would expire the link, but the server would still allow the file download to be resumed (but not restarted).