Thanks for the response!
While I agree with your points about upgradability, I think this falls more under preference and tradeoffs, just as you said, it’s not about choosing the technically superior option. My main issue with this decision is that it feels big enough to not be in the scope of the functionality upgrade itself-proposal cancellation.
Changing the upgradability strategy of the DAO contracts is a very serious deal, and maybe this should be a decision in itself. This affects how the future upgrades are done, affects the ease of indexing of historical data forever, and potentially can require completely different indexer implementations for all 3rd parties in the future if new upgrades change the implementations a lot. I’m not arguing against different upgrading strategies or the proposal cancellation functionality; I’m arguing against changing the governance upgrade strategy now, to the level where I think this is a more important discussion than the proposal cancellation functionality itself. Considering the current contracts are upgradable, I could argue that the DAO’s current stance on this topic is that contracts should be upgraded through proxy implementations rather than replaced. Changing the upgrading strategy of the contracts is a one-way door which we cannot come back to and “fix” once historical data is split.
If we proceed with the decision to make a new deployment and adopt this new upgrading strategy in the future, it’s unclear why then the new contracts implement the upgradability function. It feels like taking on the complexity risk without fully utilizing the benefits.
I am overly simplifying this, but it’s just as if instead of painting the walls, in order to avoid spilling paint on the floor, we’re building a new house next door with walls of different colors, which can be painted over either way.