I have a process objection. This grant has already been vetoed by ZF and Shielded Labs, and the veto is valid according to the conditions of ZIP 1016. Bootstrap’s objection is invalid.
Once a grant has been vetoed, having a vote on whether to rescind it is not consistent with ZIP 1016:
If a grant is vetoed after passing a coinholder vote, then payments for it MUST be stopped.
Vetoes not only do not require, but do not allow for coin-holder approval. It is designed that way partly, although not exclusively, because one of the cases in which a veto can be applied is the case of a coin-holder vote for a grant that the Key-Holder Organizations could not legally pay. Bootstrap or ECC would have to resubmit the grant application in order for there to be another vote on that new application.
It is very intentional that a valid veto is irreversible for a given grant — that is necessary for definiteness and predictability of the veto mechanism. It does not prevent an identical grant application from potentially being re-approved if it is resubmitted (although I think it is unlikely that an identical grant application would be re-approved in this case).
The Key-Holder Organizations could have, consistently with ZIP 1016, called a vote on whether to re-approve the existing grant, but ZF and Shielded Labs chose to veto it instead. These are alternative mechanisms: one or the other can be used, not a mixture of both.