Thanks for the suggestion @kiko.
We've thought about this, initially we wanted an internal function
_votingPower(tokenId) that could be overriden by the user. But it turns out there are a few challenges to implement this.
The first is that the delegation mechanism is intended to make trading undelegated tokens efficient, by opting out of (or rather, never opting in to) the tracking of history of balance changes (i.e. voting power changes). If we allow different token ids to have different voting power, the moment an account goes from not delegating their tokens to delegating them, we need to know how much voting power has to be added to the delegate. The only way to know this amount appears to be to keep track of it as tokens are traded, which is the cost that delegation was trying to avoid. It wouldn't be exactly the same cost, it's a little less, but it's still non-zero overhead.
A second challenge is the question of whether voting power for one token id stays the same throughout its lifetime, or if it can change dynamically. If it can change dynamically that makes tracking voting power more complicated, and it wouldn't be as simple as overriding the
_votingPower function. The fact that people may do this accidentally and we can't prevent it in the design of the contract was also a strong reason why we decided against implementing this feature.
It would definitely be valuable but we decided it was better to ship the feature with 1 vote per NFT.
It would be great to see someone experiment with votes where it can change. You can even build on the
Votes abstraction which would make things a lot simpler.