The scenario in figure 8 isn't something we can solve or avoid.
The scenario basically explains why a leader cannot commit an entry from a previous term UNTIL AND UNLESS there is a newer entry in the current term that has been replicated. Once there is a newer entry in the current term and it is replicated successfully, the entry from the previous term is "safe" since it can now never get overwritten, and thus Raft can go ahead and commit it.
From an implementation point of view, nothing needs to be done since the code that commits entries and say, sends them on a channel, will "walk" through the logs it has and commit each and every log up until the log from the current term. This will make sure that the logs from the earlier terms are committed only when there is a newer log with the current term that is also ready to be committed.
Raft is... genius!