I found this use case: RFC 8702
"Use of the SHAKE One-Way Hash Functions in the Cryptographic Message Syntax (CMS)": https://www.rfc-editor.org/rfc/rfc8702.html

Another possibility for digest&sign API: it is possible to determine the length of required hash function by the underlining field Fp of the curve in use. Then, use this length instead. It's better than to (try to) get the length by _gcry_md_get_algo_dlen (for SHAKE, it's undefined).

Fixed in both of master and 1.10 branch.

For libgcrypt, initially when the code was put, it made some sense.
Now, it's useless, so, let's simply remove the message.

Added: rC547dfb5aecc1: cipher:ecc: Add selftests for EdDSA.
Added: rC3ac2bba4a4b1: cipher:ecc: Implement PCT for EdDSA.

I have now disabled the rewriting in the 2.4 branch. Those who want to keep the old behaviour may add

could not trigger it with the described steps on windows

works for 4,1 GB, too.
(Tested with Gpg4win-4.2.0-beta346)

Move back to the backlog and trigger re-evalutation of priority (which was high).

And of course we also need to adjust GPGME

We also need PROGRESS lines in gpgsm.

I agree that the "future" won't come, ever. (for libgcrypt)

works

works

It does not work as described for subkeys with later expiry dates if the primary key has already expired:

I doubt that we will ever be able to use the flexible array thingy. The old pattern has been used for nearly 50 years and replacing it will just introduce bugs.
Do you use offsetof for that reason?

I found that for EdDSA other than pure Ed25519, it can supply context.
I changed the semantics and API for adding context and input data, as we need to support both simultaneously.

I changed the lg-input-data.diff patch not to break the ABI, reusing the published symbol of gcry_pk_random_override_new.
With this approach, if/when needed, backporting may be easier.
Drawback is debugging internal of libgcrypt will be a bit confusing.