With one of the recent merges, the list of default KEMs was significantly reduced (commit ddc21b0).

While there are ways to specify non-default KEM for openssl s_client/server, this causes issues for situations where the curve can not be explicitly specified (e.g. cURL) but has to rely on whatever OpenSSL API exposes as defaults.

May I therefore suggest to use a slightly different approach than just brute-force disabling: I'd like to propose the use of build defines to allow a fine grain selection of which KEM alg is enabled and which is not.

In ssl/t1_lib.c:
(A) For each KEM which should be enabled by default, use:

#ifndef no_<KEX>
0xabcd, /* description*/
#endif

(B) For all other KEMs, use

#ifdef with_<KEX>
0xabcd, /* description*/
#endif

<KEX> obviously would be a KEM name, like kyber1024 or p256_newhope512cca. 0xabcd is the placeholder for the related KEM 16-bit code.

To keep the code readable, a further layer of define wrappings is proposed to be used to wrap the two defines above into a one-liner each, like so:

#define check_disable_KEM(code, name) ... /* for the KEMs enabled by default */
#define check_enable_KEM(code, name) ... /* for the KEMs disabled by default */

During build, one can simply add (just as examples) -Dno_p256_kyber512 and/or -Dwith_kyber1024.

Anything that speaks against such an approach?

I'm fully aware of the desire of the OQS team to have control over available KEMs and that long default lists can lead to ussues.
On the other hand, OpenSSL also allows enabling/disabling algos during build time - and I do have an issue now being unable to use kyber1024 in my test environment.