Hey @alextnetto.eth thanks for taking my post seriously and looking into it! I was aware of the inheritance model, what I missed was that this version of GovernorTimelockControl keeps its own internal mapping of timelock ids, rather than relying on the Timelock’s storage itself, which is cleared when the proposal is cancelled in the timelock.
Practically what this means is that a proposal cancelled in the Timelock will be stuck in the “Queued” state forever. While obviously not ideal, this is certainly better than being re-queuable, and probably acceptable if the intention of the veto is only for emergency situations. I do think it points to the fact that this “solution” is very much a hack, both from the technical and social side, and ideally we will find a more sustainable way forward. But I’m relieved this works for now.