One thing I’ve been considering with my initial proposal is perhaps modifying the “lookback” to see if the fork acivates. Possibly reeling it in from 1000 blocks to 10.
My principal motivation for such a large number was to keep a chain re-org from causing the fork to launch then pull back. However I think we could handle an abandoned activation.
What a lookback of 10 would accomplish is it would keep ommers from containing conflicting activation blocks that may or may not activate. Clients should be keeping at least 10 blocks in memory to deal with possible chain re-orgs. (IIRC geth handles up to 300 before issues start developing).
Keeping the activation at 1000 blocks reduces the search space that clients would need to examine if they are searching for the activation without any configuration hints. The EIP would continue to be updated with the observed block for clients to work off of. Once we get a finality gadget these observed blocks numbers would be as final as the gadget makes the chain.
So at x%1000 = 0 we fork if the time of block x%1000=990 is past the activation time.