Suppose there are two possible policies (P or Q) that the network could follow at the choice of the delegates.
Suppose 40% of the network will vote for delegates who support policy P but never those who support policy Q, while 60% of network will vote for delegates who support policy Q but never policy P.
I think bytemaster's goal in proposing this change is to incentivize delegates to move from policy P to policy Q in this situation. With the intent of creating consensus -- reaching equilibrium when all delegates support Q. [1]
I thought at first that this would happen -- delegates would always be incentivized to move from P to Q in order to raise their max payout. Because moving from P to Q would always increase your approval rating from 40% to 60%, regardless of how many delegates currently support P or Q.
But I thought a little more and realized this is not actually the case. While the GUI tells the user they can vote for any number of candidates, in actuality each BTSX can only vote for up to some maximum number of delegates K (to keep bytes per transaction reasonable). The Q supporters have 0.6 * M * K total votes, while the P supporters have 0.4 * M * K total votes, where M is the total number of BTSX in circulation. If there are N_P delegates who support P, and N_Q delegates who support Q, the average number of votes per delegate for each faction would be:
A_P = 0.4 * M * K / N_P
A_Q = 0.6 * M * K / N_Q
At equilibrium we must have A_P = A_Q (otherwise delegates would switch to the other faction to increase their payout):
0.4 / N_P = 0.6 / N_Q
Which simplifies to:
0.4 / 0.6 = N_P / N_Q
In other words, the equilibrium actually occurs when the factional proportions of the delegates reflects the factional proportions of the population. I think this will happen as long as the number of approvals is limited by K, which in turn is a fundamental consequence of limited bytes per transaction and large pool of delegates, which cannot be overcome without increasing bytes per transaction (increasing bandwidth and storage requirements for everyone) or decreasing the number of live delegates from 100 to K (greatly increasing centralization).
One solution to the conundrum might be to allow transactions that ignore the limit K and vote for up to a full slate of 101 delegates (or 151 if we increase the delegate count), but requiring such transactions to pay R times the normal fee, where R is equal to the size of the transaction divided by the size of a normal transaction. Thus, K becomes a "soft limit" where exceeding K merely leads to an increase in fees, whereas AFAIK currently K is a "hard limit" (transactions which attempt to vote for more than K delegates are simply rejected).
[1] Under the simplifying assumption that delegates always set their payout to 100%, are thus actually paid proportional to their approval rating, and only care about their payout rate. I.e. this model doesn't consider delegates who set lower payouts to gain approval, or delegates who believe in a minority opinion for ideological reasons and are willing to accept a lower payout as the price of keeping their principles (although both of those are quite plausible real behavior of real delegates; indeed, enabling the first option is the reason why the client allows delegates to set their pay rate!)