We will be voting NAY on retroactive referenda of these characteristics, specifically of high value. To us, it is a better way to outline a plan of action to follow what deliveries were fulfilled and what deliveries were not fulfilled as opposed as this high value retroactive approach which leaves the tokenholders footing the bill
for work that was not approved beforehand. For this referendum in particular, there is a denied precedent with referendum 1325 so any specific changes proposed to OpenGov should have been presented as a non-retroactive referendum presented for approval instead.

So we prefer that well known teams such as these one as well as newcomers to take the non-retroactive route exclusively. This idea will be heavily enforced on our vote starting on cohort 4's term as described on our DV cohort 4 application: https://forum.polkadot.network/t/decentralized-voices-cohort-4-saxemberg/11868

Referendum 911 didn't entail an explicit retroactive second milestone hence it cannot be treated as a "pre-approved" milestone, specially when the original milestone 2 was already presented to OpenGov as non-retroactive (Ref 1325). It seems it was meant to be approved first and then implemented.

Hopefully it can be agreed by team and referendum advisors that opting for a retroactive bill specially when a non-retroactive referendum continuation was already presented (1325) and the new referendum (1499) was unannounced and un-discussed entailed an enhanced risk for OpenGov and the proposer, which is why these retroactive approaches should be considered high risk and discouraged from being commonplace. So better alternatives that align better with the will of tokenholders should be presented to OpenGov instead.

Our rationale for referendum 911 was that continuation approval would be subject to adoption so,
it will still remain as one of the two reasons for the vote in addition to the other, already discussed fact.