To me it is confusing to cancel code that do not block on IO.
How granular should opts.Context.Err() checked by the implementations ?
Between every elements in the chain ?
Between every round of cryptography ?
Should it use internal runtime options and a context callback to raise a panic (that would be recovered) inside the crypto code from the canceling goroutine (so as fast as possible) ?

Is there any reason for not doing it this (common) way instead?

func (c *Certificate) VerifyContext(ctx context.Context, opts VerifyOptions) (chains [][]*Certificate, err error) {

Is this going to involve goroutine creation for platform verifiers? Or is this not going to be used there?

I don't have a clear memory of why we didn't consider VerifyContext, but perhaps @FiloSottile does. I cannot come up with any strong reason against it versus using the VerifyOptions, and it clearly does have significant precedent.

For platform verifiers, I don't think we want to spawn goroutines and return early, since the work will still be happening, which may be expensive, and could not reasonably be cancelled. As with a couple of features of the verifiers, at least initially contexts would only be a native verifier only feature.

Since contexts are not currently wired into cryptography code (and it seems unlikely we'll do that, at least at this point) the context will only be consulted between chain building operations (i.e. each time we consider a new certificate for addition to an in process chain, essentially at each invocation in a DFS).

My understanding is that Verify (and by extension, VerifyContext) returns all the chains that it can build. However, in most cases (e.g., TLS handshake) you really only need one valid chain. So if the context expires in the middle of chain building, but we have at least one valid chain by then, what is the expected behavior?

I don't have a clear memory of why we didn't consider VerifyContext, but perhaps @FiloSottile does. I cannot come up with any strong reason against it versus using the VerifyOptions, and it clearly does have significant precedent.

Nope, not sure why we went with VerifyOptions.Context instead of VerifyContext. Maybe just because it was there and we're used to adding things to it. VerifyContext sounds straightforwardly like the right choice, though.