Unless I am misunderstanding your statement, I do not believe that is correct. I believe that a resend would only be sent out if there is an error, an invalid, or there is no reply. The no reply would only come after the deadline of 7 days has passed. The resend would then have a deadline of 3.5 days (half of the original deadline) which should still be sufficient for most machines deemed reliable by WCG algorithm for re-sends.
Edit: If you notice on mine, which ran for a little over 5 days, it completed within the 7 days and there was no resend sent out. The quorum is 2 and the other one only ran 22.39 hours.
Cheers

You're wrongly assuming a lot!
I'm running many projects at the same time at only 25% cpu. Also I didn't know how long a task would take. BOINC doesn't show an Actual Estimated based on actual time per computation. 1 hr remaining could be 4 actual hours based on settings! And like microbiome, it could run for hours showing no progress. 3-4 weeks would work. 1 year is ridiculous.

Your OP gave such an abundance of information, and in the absence of further replying on your part...

1) BOINC does give an initial estimated runtime based on the compute capability it tells the project server it has and then will give remaining estimated runtime.
2) MIP not showing progress for hours is about the time they finish on my machine. It shows regular progress in highly granulated percent fraction.
3)At 25% of CPU time or CPU threads? Assuming time, the crunch would take around 4 calendar days, if on 24/7. Running many projects, I'd say if an ARP hits your machine and BOINC learns of the sciences specifics, it's likely to run in high priority.

More assuming on my part: I think your BOINC configuration is broken. If not already done so before, at the very least switch on Leave Application In Memory, when suspended, as else an interrupted task unloads and regresses to the previous checkpoint, loosing the progress a task has since made.

lavaflow

My post of 22 hours ago referring to re-sends after the half-way point referred to errors, invalids and aborts after the half way point and also to no reply which would be at the end point of the 7 day deadline. All of those circumstances would generate a re-send with half the deadline. If before the half way point then they would be sent with the full deadline.

Mike

"If before the half way point then they would be sent with the full deadline."
Novel to me. Until just now always thought that the base deadline of a resent was half the original deadline (7 in case of OPN1), which was until not too long ago 30-35% but caused the feeder clogging in circumstances, so uplinger upped it to half, 50%. The doubting Thomas I am, I went to look for OPN1 log copies of _2 that got recently issued to my machine, more than I ever thought, so guess that answers the reliable state as well:

Result Name             Receive Date             Deadline
OPN1_0007543_08171_2	17/08/20 03:06:37	23/08/20 08:37 > 3.5 days but less than 7.
OPN1_0006958_07277_2	16/08/20 08:04:53	19/08/20 01:43 < less than 3.5 days
OPN1_0007394_06025_2	15/08/20 17:14:47	21/08/20 23:28 > 3.5 days but less than 7.
OPN1_0006628_03918_2	15/08/20 07:14:48	16/08/20 17:31 < less than 3.5 days - Not even 1.5 days
OPN1_0006747_09877_2	15/08/20 04:57:55	18/08/20 00:03 < less than 3.5 days
OPN1_0006846_02540_2	14/08/20 15:58:45	17/08/20 10:22 < less than 3.5 days
OPN1_0006668_01999_2	14/08/20 04:41:59	16/08/20 21:38 < less than 3.5 days
OPN1_0007329_11044_2	13/08/20 11:49:23	19/08/20 17:23 > 3.5 days but less than 7.

The timespan allowed is all over the place, just not the full 7 the original had. It seems to suggest what I speculated on "Can't remember if resends issued before the original deadline halftime (error, invalid) get full original deadline or something that equates to original deadline minus time already passed." i.e. the deadline same as the original.

Oddly, there are those that get less than 3.5 days, sometimes close or less than 2. Maybe it's half time of half time in instances. Clear as mud.