Is that correct though? If the masternodes refuse to update their clients to the protocol version that the devs release, then wouldn't that be the final say?
Definitely yes, if the testnet release is the equivalent of opening it up to feedback, then we'll do that, but I just think it would be a better usage of everyone's time if the development direction was hammered out *first*, and then implementation, and then bugfixing. Not implementation first, and then development direction and bugtesting at the same time.
Absolutely not. You're mixing up some fundamental concepts. Let me try to explain
If 12.1 is a protocol change, then MN ops need to update, otherwise they loose payouts and voting power. Nothing else happens to the network. If it's not a protocol change, then don't need to update. Could be a bug fix for something else. But obviously, 12.1 will be protocol change that affects masternodes.
If 99,99% of Masternodes do not update, 0.01% of those who update will earn quite a lot of Dash proportionally. We've had numerous occasions in the past where multiple versions of the cliente coexisted in the Masternode network. But essentially, nothing structurally happens to the network.
The opposite happens with miners. If Dash rolls out a version that the miners do not agree and don't update, then the network does not update, even if 100% of MN ops update. In that case a strange paradox happens. The original Dash (lets call it Dash-A) chain continues, and whoever wants to follow the shortest chain (Lets call it Bash-B) is welcome to do it. The longest chain Dash-A is left by itself with no one to code for it, as it is Evan who owns the repository. Then the miners would have to all get together and find someone they collectively agree on, fork the Dash repo, bring out a new client and fork the blockchain into another chain (Dash-C). The original Dash chain would essentially stop rolling. After some time, Dash-B would be longer than Dash-A, and network would reconciliate, simply orphaning all of Dash-B's invalid blocks, and all would be resolved.
Testnet is 100% about opening up to feedback. That is the whole point of testnet. You must understand that implementing is not as simple as "hey, how about this XYZ idea of mine?" - it involves massive amount of coding and dependencies between logics. One must absolutely do their thing in one way, and one way only, for code to behave as intended. Development direction is decided by Evan and whoever he believes are good councillors. They extensively debate on a idea, and start coding solutions for it. It is not rare (as precisely again with 12.1 and Sentinels) where while coding, new ideas pop-up in his head.
They weave it all together, and when the team is confident something is really close to final draft, it's released on testnet to see how it behaves in a controlled environment in the semi-wild. People pick it up and try to understand it and break it. It is THEN that you fully understand the implications of his words in interviews, and only then you actually see what is happening. And then you have direct access to debate with the devs.. not because they are ignoring (which they are certainly not) ... but because they are now available to look at what's happening and what people think. People find bugs, or they say "hey how about this feature to work with that issue" within the predefined logic... If an idea is possible and works for the direction and vision of the project, they may very well implement it for a future 12.2.