Submitted by smilingheretic_
ERC20Gauges.sol#L214
ERC20Gauges.sol#L257
ERC20Gauges.sol#L248
ERC20Gauges.sol#L465-L469
The impact depends really on how gauges are used by other contracts.
The most obvious consequence I can imagine is that some other contract distributes rewards based on calculateGaugeAllocation. However, because _getStoredWeight(_totalWeight, currentCycle)  is now larger than the real total sum of weights, all rewards are smaller than they should be (because of larger denominator total).
There can be also (potentially large) leftover amount of rewards that is never distributed because now sum of  calculateGaugeAllocation(gauge, quantity) over all gauges with constant quantity is less than quantity. So value might be lost.
I added this test (modified testCalculateGaugeAllocation ) to ERC20GaugesTest.t.sol and it passes.
As we  can see, we can call token.incrementGauge(gauge2, 1e18) before token.addGauge(gauge2). This is because this check doesnt revert for gauges that were never added in the first place.
First time the total weight is incremented in _incrementUserAndGlobalWeights and 2nd time here.
If corrupting state like this is adventurous for someone, he can frontrun token.addGauge called by the admin with a call to incrementGauge which is permissionless.
Foundry
Use condition _gauges.contains(gauge) && !_deprecatedGauges.contains(gauge)  to check if a gauge can be incremented instead of just !_deprecatedGauges.contains(gauge). Theres a function isGauge  in the contract that does exactly this.
Joeysantoro (xTRIBE) commented:
0xean (judge) commented:
thomas-waite (xTRIBE) confirmed and commented:
