Few comments on the patches.

Our own internal function signatures is not necessarily a good refernce. The main objection to all what you list above is the lack of explicit length information. For each uint8_t* there should also be a size_t ...len in my opinion. Otherwise the API will be highly prone to memory access errors.

@fse Thank you for your comment (quick ! :-).

The API that you quote at the end is indeed what is comonly understood as how a KEM functions and is exactly what fits to ML-KEM.

Please send us patches (to this branch).

One question on the future cooperation: is it from now on possible to directly commit to these branches or will we continue to work with uploading patches to this task?

Pushed the change into kem-kyber branch.
https://dev.gnupg.org/source/libgcrypt/history/kem-kyber/

I'll create a branch for this work. Then, I'll incorporate changes to master.

Uploading two patches for review: