In gpgme this causes the algorithm to be reported as E_error (EdDSA):
$ gpgme/tests/run-keylist --verbose --from-file .../gnupg/tests/openpgp/samplekeys/ietf27-mlk-nistbrain-pub.asc keyid : 1620EB12B7A8EE2D can_cap : esc has_cap : esc flags : upd : 0 (0) fpr 0: 1620EB12B7A8EE2D38CD1834ABD1CF0E094A44D30C73ECA6A198089705116D37 algo 0: E_error (EdDSA) caps 0: sc flags 0: [...]
List packets shows that the key lacks the curve OID:
$ gpg --list-packets .../gnupg/tests/openpgp/samplekeys/ietf27-mlk-nistbrain-pub.asc # off=0 ctb=c6 tag=6 hlen=2 plen=42 new-ctb :public key packet: version 6, algo 27, created 1788439446, expires 0, pkbytes 32 pkey[0]: 72A17F2752E2FAF59598AF0039A41C921C3402FCED171FD1040D887379F40C13 keyid: 1620EB12B7A8EE2D
For comparison, for a Curve 448 key --list-packets gives
# off=0 ctb=98 tag=6 hlen=2 plen=73
:public key packet:
version 5, algo 22, created 1727082581, expires 0, pkbytes 63
pkey[0]: [32 bits] ed448 (1.3.101.113)
pkey[1]: [456 bits]
keyid: 1DE1960C29F97E67i.e. pkey has size 2 and pkey[0] contains the (binary) OID.