1) Delegates are already a trusted source and continually competing for the approval of "shareholders".
The purpose of my proposal is to separate out the roles. The delegates are elected only for a specific role: keep the DAC functioning, include all valid transactions, and maintain consensus in the blockchain. They also have to maintain price feeds but that role can even be delegated to others if necessary in the future. With my proposal they would have one more role: publish and approve proposals to become available for shareholder ratification if the proposal seems to be a reasonable one that shareholders might approve. Every other role can be delegated to other entities who are specialized to handle that role.
2) Asking shareholders to consider 1001 individual proposals AND vote for 101 delegates would increase transaction sizes 10x because at a technical level, voting for a proposal and voting for a delegate are tied to shares not people and thus every transaction affects the votes / accounting.
I am not sure what you are envisioning the implementation to be, but let me tell you how I envision it. There would be at most 4 active delegate proposals at any given time (Slot 0 to Slot 3). Any delegate could suggest a proposal for a given slot. If at least 51 delegates approve of the proposal, that proposal becomes up for consideration at the given slot (replacing any proposal already in that slot). If 51 delegates agree, they can also remove a proposal from a slot at any time.
Every transaction with BTSX stake as an output balance would have just 5 extra bytes attached to it. Four of those bytes would designate a block number N in the past. The signatures of the transaction would be modified to not sign the hash of the transaction but rather hash((transaction hash) concatenated with (block N hash)). For the transaction to be valid for inclusion in a block, the block N would have to be far enough in the past in the blockchain such that 51 unique active delegates have signed blocks adding on to the designated block (meaning the block can be as early as 8.5 minutes in the past). This is basically TaPOS. The fifth byte attached to the transaction consists of a sequence of four 2-bit flags. These flags refer to the respective proposals up for consideration in each of the four slots (if they existed) by the time of the block N. One of the bits of the 2-bit flag designates whether the transaction acknowledges the existence of the proposal in that slot. If it does, then the second bit of the 2-bit flag designates whether the stake is voting in approval or disapproval of the proposal.
This way, with just 5 extra bytes, it is possible for shareholders to vote yea or nay on any of the up to 4 active proposals. Having four proposals simultaneously can be useful, because some of the proposals may require a longer period of time to get the necessary votes before ratification. For example, a proposal changing the inflation caps may require majority approval. That proposal can sit in slot 0, even as other more urgent proposals get added in and ratified earlier (because they require less shareholder participation to get ratified).
3) If proposals should require X% of voter turn out and X% is higher than the minimum delegate can achieve then that is a problem. Delegates should be campaigning for high approval and increasing their pay when they are elected is a major way to do this.
4) It has already been pointed out that apathy is the default mode when "everything is ok".... but as soon as there is a threat suddenly everyone cares. This will drive voter turnout for delegates and improve security.
I agree that low minimum delegate approval ratings are a problem. And
maybe your proposal is a clever way to reduce voter apathy and scare shareholders into increasing the minimum delegate approval rating which in turn increases blockchain security. But what if it doesn't? Then like I already pointed out, we risk inflation even when only a relatively small percentage of the stake wants it. I think inflation rates are a very big deal that it should only be adjusted with majority shareholder agreement. And even if we got the minimum delegate approval above 50%, it still doesn't change the fact that this method is less agile than the proposal system. For example, there is no way to print a lump sum of inflated stake to pay for large unexpected expenses (for example legal expenses). And even for continuous slow inflation, it still requires the (in my opinion) inelegant hack of a delegate registering a new account to be voted in to replace the old delegate every time they want to adjust the inflation.
5) Allowing the delegates to approve spending bills like a congress is the "delegated approach", but this approach doesn't give shareholders a chance to review and grants many low-trust delegates (those only trusted to sign blocks) a blank check.
I am not sure which system you are comparing to here. But it is certainly not the proposal I am making, since it requires shareholders to directly ratify any of the delegate's proposals with their votes before they become active. And what you are saying here actually supports my argument. People are voting for and trusting delegates for a very specific job. Why unnecessarily entangle another very important role (managing funds for development, marketing, legal, etc.) to their job requirements? Separate roles out to entities who are specialized to handle it.