Currently, it's not possible to process certificates that have subkeys with unknown public key algorithm identifiers. Many implementations allow importing such keys either by default (for example GnuPG, Seqouia) or by providing an extra flag (for example RNP).
Generally speaking, it's a good idea to be able to process such certificate by default. It improves compatibility with new protocol versions or standalone additions of public key algorithms.
Some more context: Currently, PQC algorithms are standardized in the OpenPGP WG, see https://datatracker.ietf.org/doc/html/draft-ietf-openpgp-pqc
One possible outcome is that PQC encryption subkeys can be added to v4 certificates. In order to be backwards compatible with implementations that do not implement PQC algorithms, or not all of them, it's necessary that an implementation ignores such subkeys.
Note that the same concern also applies for the newly defined X25519/X448 algorithms in the Crypto Refresh.
Therefore, I suggest to implement the default behaviour that keys with unknown public key algorithm IDs are skipped when parsing / importing them in PGPy.
Currently, it's not possible to process certificates that have subkeys with unknown public key algorithm identifiers. Many implementations allow importing such keys either by default (for example GnuPG, Seqouia) or by providing an extra flag (for example RNP).
Generally speaking, it's a good idea to be able to process such certificate by default. It improves compatibility with new protocol versions or standalone additions of public key algorithms.
The Sequoia Interop Test Suite tests this case here: https://tests.sequoia-pgp.org/#Mock_PQ_subkey
Some more context: Currently, PQC algorithms are standardized in the OpenPGP WG, see https://datatracker.ietf.org/doc/html/draft-ietf-openpgp-pqc One possible outcome is that PQC encryption subkeys can be added to v4 certificates. In order to be backwards compatible with implementations that do not implement PQC algorithms, or not all of them, it's necessary that an implementation ignores such subkeys.
Note that the same concern also applies for the newly defined X25519/X448 algorithms in the Crypto Refresh.
Therefore, I suggest to implement the default behaviour that keys with unknown public key algorithm IDs are skipped when parsing / importing them in PGPy.