the new functions in state.go aren't actually called in any non-test functions, are you planning on doing a separate integration pass?

yeah, I'd like to get all of the pieces in place first. Once things are integrated, they'll begin to impact consensus and I want to make sure it looks good/is correct before I actually do that.

I really did not understand the goal of the proposalStepWaitingTime method.

For me, the timeout propose event should be just scheduled to occur in timeout_propose duration plus proposalStepWaitingTime.
And if timeout_propose < 2 * Precision + msgDelay, well, we risk to prevote nil at a time at which we could still accept a timely Proposal. This is a poor choice of parameters, not a wrong behavior.

The proposalStepWaitingTime method calculates the waitingTime defined here in the spec. I think we should discuss whether we want this to algorithm to just use the timeout-propose when timeout-propose is smaller than waitingTime on the upcoming spec changes. It will mean that picking the correct timeout-propose would affect liveness in a similar way it does now: if a block has not arrived by timeout-propose we prevote nil. This is the same as the current implementation, so I think that's a fine change, but I'd like further input from before making that change at the code level.

EDIT: I'm realizing that liveness may be affected by just using timeout-propose since the proposer now waits until after the Header.Time to proposer its block.