For all the perceived faults with IETs, you'd struggle to manage that with an HST.   You could possibly dispense with putting out the manual seat reservations, but the sets frequently needed "tanking" at terminal stations or it wouldn't be long before the toilets failed.

 

Purely as an example of what’s possible, from real time trains, I found a 5-car IET formed service arrive at Temple Meads from Worcester, and then depart back towards Worcester in a shade under five minutes. I wouldn’t be surprised if that involved a fresh crew taking over the train mind.

 
The inbound service, 2C77 from Cardiff, arrived at PNZ 32 minutes late, only 2 minutes before the return to BRI, 2M77, was scheduled to leave. Would 15 minutes, or thereabouts, be the minimum turnaround time for a 5-car IET?

 
I note that the forming inbound working arrived late, albeit with more than a basic turnaround time between arrival and departure - PNB time perhaps? Could the delay attribution relate to that delay? Looking at where it picked up delay, it wasn't particularly at connection points, but maybe it was a knock-on effect of another delay.

This is where the automatic 'this was due to...' lines often fall apart, as delay causes are in reality more complex. This sometimes means passengers see/hear multiple delay causes, and assume they are being lied to. The computer is programmed to state one reason, perhaps the first in the list, whereas the human picks up on the most substantial reason in the more complex set of causes, and the passenger sees contradiction.

As an example, a train I was awaiting a few weeks ago was reported by the auto-announcer as being delayed by a late train in front, but the train crew attributed the delay to a fault with the train. Perhaps its previous working out west was delayed by a late-running freight, and then ended up a few minutes late starting hte journey, before picking up a more significant delay with a fault. The fault was therefore the real cause of hte current delay, but the first delay code in the system was the original 'train in front' code. Passengers heard that explanation from the computer, didn't see a late train passing their platform first, picked up on the contradiction when the human made their announcement, and assumed someone was lying to them.

Another recent one – the CMN-PAD was cancelled CMN-SWA because of lack of train crew one morning. Then it was late starting from SWA because of a complex web of pathing issues caused by other delayed trains blocking the ECS from the depot. The first code on the system was the one giving rise to the part-cancellation, and this was given on displays and auto-announcements as "the" reason for the delay, but the subsequent delay was completely separate from this – in fact people awaiting the cancelled leg would have ended up on a later train (unless they  found out in good time and were able to travel earlier) so few or maybe none of the passengers on board had their journey disrupted by the cited issue!

 
Odd, I'm unaware of any night flights or maritime activity from Scilly. Only thought could be a delay to a connecting service 'up country' and in order to avoid blocking tracks the service was held and run late from it's source. I presume this late service is 2M77 which I note is due into EXD 13 late at 2250 (at present).