Thanks for flagging that. I certainly agree that the use of single choice-voting is suboptimal.
Ideally, we would use multiple choice-voting but, regretfully, that is not possible at this time due to a shortcoming in our current governance framework.
This leaves us with making the best out of single choice-voting.
To your point, I can absolutely see that scenario where a certain voter would like their vote to be counted towards less exhaustive options, too. Although I wonder whether that is strictly true across all scenarios. There could be a voter who feels strong about milestone E and votes for option 3 purely because milestone E is included, but if option 3 would not pass, they would rather vote for ‘make no changes’ or ‘abstain’ instead of option 2. That just seems like an assumption that is hard to generalise and, again, falls back to the constraints of single-choice voting which we’re bount to, when ranked choice-voting could be applicable here.
As dissatisfying as it may seem, due to these constraints in the current governance framework, the current draft appears like the best possible option in this suboptimal solution space we’re constrained to. At the end of the day, this proposal will merely serve as a signal and not take any on-chain action in itself. By the time future SEPs like the actual vote on enabling transferability will be voted on, we will have had a chance to improve our governance framework in the meantime – which is why milestone C is such a crucial one IMO to make sure that the proposals ratified by SafeDAO are maximally legitimate and accepted.