Let assume that we are in the period after GST. A correct process p sent Precommit id(v) message at time t in round r. By validBlock property, every correct process that enters round r+1 should receive the same Polka p received before leaving round r.

The process p received valid Proposal and 2f+1 matching Prevote messages at time t. At least f+1 of those Prevote messages is from correct processes, and let denote this set of correct processes with C. By majority intersection property, any set of 2f+1 Prevote messages in round r contains at least single message from the set C. Let denote with time t1, the earliest point in time a process from C sent it's Prevote message in round r.

Note that a correct process can't send Precommit message before receiving 2f+1 Prevote messages. Therefore, no correct process can send Precommit message in round r before time t1.
If a correct process q send Precommit nil message, this implies that he waited timeoutPrevote before. Therefore, no correct process can send Precommit nil before time t1 + timeoutPrevote. Let assume that some correct process q received 2f+1 Precommit nil messages at time t1 + timeoutPrevote. According to current version of algorithm, q will start round r+1 at time t1 + timeoutPrevote.

If a correct process has started timeoutPrevote at time t1, this implies it receives 2f+1 Prevote messages. Therefore, every correct process will start timeoutPrevote the latest at time t1 + Delta (as we are in period after GST). So the latest point in time p can send Precommit v is t1 + Delta + timeoutPrevote.

Note that if a faulty process sends Prevote v to p just before timeout expires, p might send Precommit v at time t1 + Delta + timeoutPrevote, and process q at that point in time already left round r.

The potential solution for this issue is introducing timeoutPrecommit in case a process receives 2f+1 Precommit nil before it starts round r+1.