Blocktrades and I had a nice discussion on this; and I wanted to also present publicly here my suggestion for achieving both his goal of "high confidence" on the latest block, as well as my goal of conclusive BFT and finality.
In essence, the issues that arrive with treating a single phase of votes on a given block as evidence of global finality (not exactly what this proposal's goal is, mind you, but what my goal would be) is resolved by having a 2-phase approach: a pre-commit phase, and a commit phase. During the pre-commit phase, votes for a block are collected. During the commit phase, if enough votes are collected, the commit phase begins, and again if enough votes are collected the block can be treated as final and irreversible (by BFT constraints). This 2-phase approach is well known in BFT strategies and is what is employed by methods like PBFT and Paxos.
This two phase goal could also be achieved without added extra messages by appending the commit-phase messages for block N-1 (assuming you have enough pre-commit messages), into the pre-commit phase votes for block N.
In this way, we would rather declare the pre-commit votes for block N as a presentation to the network of high-confidence (this is Blocktrade's goal) in one block. But further, in the best (and average case!) we can also conclude and present true finality for block N-1. If consensus used this true finality, we would avoid any potential soft-lock issues or split consensus on irreversibility that would come with treating the high-confidence single phase as truth. dApps could choose whether to use the high-confidence metric or the finality metric for their own use-case.
Granted, this is more work and could be done afterwards, but I think achieving proper BFT and finality should be a goal for Hive, and is definitely achievable without extra p2p messages compared to this proposal.
I have some other work I need to do tonight, but I'll think about this proposal tomorrow.
I very much like this approach. I would add a soft/marketing benefit of this is that in crypto projects it is extremely important to avoid FUD vectors when possible (even if the FUD is out of context or nonsense, it can be harmful, or at best a distraction). Something that probably will work in practice can still be very vulnerable to FUD, but something that is feasible to show always works is less susceptible.