That’s not true, a good bft protocol will resume once network conditions stabilize.

And how, exactly, will the "network conditions stabilize" if over 1/3 of the votes are malicious, and thus able to prevent the honest voters from ever agreeing on anything ever again? Are you betting that the attacker will just get bored and walk away?

Also, what a confusing choice of words. A distributed system is BFT (or not BFT) regardless of whether or not the underlying message broadcast medium is synchronous/asynchronous, or reliable/unreliable. The "network conditions" being "stable" have no bearing on the voters' ability to reach agreement -- that's solely a function of whether or not f or fewer votes are malicious out of 3f + 1 votes.

I was talking about network conditions, not a threshold of malicious participants (in which case yeah you will have liveness issues).

Your second paragraph is false also. Different BFT systems have different assumptions. Some work in asynchronous settings, some work in semi-synchronous settings, etc.

You should consider rereading Leslie Lamport's original paper. BFT is a property of corrupt votes, not the network. You keep trying to make it about the network. Like, if you want to have a conversation about how the network can influence the system's fault tolerance, you should instead consider the network topology -- as in, which routes between honest nodes include corrupt nodes. This is also considered by the paper, since corrupt nodes can censor or rewrite messages, and thus influence how many corrupt nodes the system can truly tolerate, given a network topology. But in no case does message delay give a BFT system's node an excuse to make forward progress without first verifying that at least 2f+1 replicas agree with its decision. Even voting on a view change to remove a presumed dead node requires a 2f+1 vote.