These are good, in-depth questions.
Unless every owner a token is going to be online mining all the time, then mining will need to be delegated. So some pools have more weighted-balance voting power than others. You need to offer some incentive for mining. Profits accrue to those with the most economy-of-scale if the incentives are market (competitively) priced, thus you will likely end up with the situation that Bitcoin had where a single pool or potential grouping of large pools had more than 51% of the hashrate but in your design this would be more than 51% of the voting power.
Since we don't use mining to order transactions or resolve forks, adding mining for the initial distribution would be rather vestigial. It also seems that so far, despite everyone's best efforts to make mining more distributed and focus away from large pools or enthusiasts, we've only achieved moderate success. In the end we want the initial distribution to go to people, not hardware so we're distributing 100% of the supply through a captcha on the site under "Get Blocks" according to a fixed distribution schedule. https://github.com/clemahieu/raiblocks/wiki/Distribution-and-Mining
Is a cascade of intertwined inter-chained reorganizations when multiple double-spends are reverted by a fork more onerous than in a single block chain? Isn't that complexity similar to the reason you
rejected multiple inputs and outputs in transactions?
The rollback does cascade though the window for a rollback is very small compared to traditional cryptos. On a traditional crypto block_interval * confirm_count is the range of uncertainty, with RaiBlocks the range of uncertainty is ~1 network propagation interval i.e. how fast can network packets reach everyone in the network. Once everyone has received one fork, subsequent forks would be instantly rejected.
The key failure in your design is the lack of incentive to have a consensus. What is the incentive for voting nodes to agree with the correct fork and for minority nodes to agree with the majority fork? Seems to me they can all disagree and no one can prove otherwise, because they can pretend to have never heard the votes of others (no way to prove receipt of a vote on the internet). This shows that without the objectivity of a PoW, then there is no objectivity and you end up in chaos.
Primarily this is mitigated by the fact that if a node doesn't create a fork, there is nothing to vote on, no consensus is needed. If I have a signed block chain A0->B0->C0 and it's published, no one can vote between C0 and let's say C1 because there is no signed C1. If you don't sign forks, no one can vote on your transactions.
In PoW, miners have an incentive to reach consensus because otherwise their rewards won't be honored by the longest chain. In your system the majority of the vote is the winning fork, except there is no penalty for delaying for an indefinite period acknowledging receipt of such a vote. Thus complex game theories arise. Even more critically, the majority vote may be split among multiple forks, such that there is no consensus, because you have multiple chains thus a plurality of permutations of forks.
I do want readers to note which of the three posters in this thread was able to state directly the design error. That should be instructive to investors.
Well-behaved nodes are configured to flip their vote if they observe their fork variant as having fewer votes than another. The only way to vote is to have a balance tied up in the network. To vote to confuse the network is to destroy its value which destroys your investment. The incentive is to retain value in the system rather than accumulate rewards through inflating everyone else.