The last log stated a few hard truths that were not considered in the first iteration of the protocol.

Let's now consider how a frame is defined: it is a run of data trits followed by an ACK trit. All are acknowledged by trits from the peer, their values could have meaningful data, that are unrelated to the frame (or not, or whatever, it's a trit, so it works for the self-clocking scheme). This is not enough if the ping-pong must cease when both peers have nothing left to transmit. So let's think about how to agree on stopping, then from there we'll see how to restart later.

As noted before, a new frame can immediately follow another so one ACK can't stop the ping-pong right away. Two can, though, but if you can count to two, you can count to 3 with as many DFF and few gates. So if the peer is the last to send data AND has already sent 3 ACK, then it may stop the ping pong by not aknowledging the peer's ACK to the ACK to the ACK to the.... The other peer (which did not send any data) simply ACKs everything. This leaves the link in an unambiguous "well known state". Of course, if the peer receives a data trit instead of a ACK during the last 3 cycles, this means that the other peer will stop by itself, and this peer inhibits its own ACK inhibition. The ping-pong ensures that the state of the whole system is known at all times, and coherent, and easily deducible from the known information.

If we know the state when the ping-pong stops, and the conditions of stop, then we can safely restart it. Though there will also be cases when it is unknown and the race conditions must be considered, in particular in the cases when both peers want to resume talking at the same time. That's where things become tricky but just follow the reasoning...

IF the protocol resumes pingpong with another ACK, there is an uncertainty because the receiving peer (which might have sent a request right at the same time) can't know if the ACK is in reply to its own ACK. It might even mistake or even miss the ACK if the timing is too tight for one of the peers, for example by sending the ACK right after the last ACK that closes the sessions. In that case, it's like the receiving peer didn't see the 3rd ACK and the 4th looks like the 2nd. The ambiguity is strong here!

So the solution is to resume not with a ACK but a data trit, which removes the ambiguity.

But this only pushes the ambiguity further because then it becomes a temporal ambiguity: which peer is the first and should take the initiative ? If both peers wake up during the same sampling window, there is nothing to distinguish them because they are absolutely symmetric. They should be considered identical and mirrored so if one peer does something, the other does it too. Except for the clock but we can't reasonably wait until the clocks get significantly out of phase, the matter should be solved in one or two cycles ideally...