It would be quite involved to implement.

The sub-PKEY objects do not have to be from the same provider as the hybrid algorithm, so no assumptions can be made about it's implementation. At least for the default provider (FIPS is different as usual).

Once retrieved, the keys would have to be wrapped by libcrypto into EVP_PKEY objects. This means that the hybrid provider would have to have a means of passing the associated dispatch tables back to libcrypto.

Not impossible but not straightforward.

To mimic the functionality given in oqsprovider, i.e. being able to access the public/private keys of each component as a array of bytes (instead of returning an EVP_PKEY * structure that holds the value), wouldn't it be a matter of just adding those algorithm-specific octet string params, as @t8m mentioned, and accessing each of the values from each of the sub-PKEY object that hold the classical and the PQ info?

You would, up to a point, "delegate" the way each of the values are accessed on each sub-PKEY element to the particular provider implementation of each of the algorithms, but wouldn't be a need to be re-wrapped into EVP_PKEY objects.

Yes, it would be possible to add functionality to do the equivalent of a to_param call for the sub keys (one at a time). The output from this could be imported into another provider via a from_params call. It's a bit of a roundabout way of doing things and wouldn't result in a shared PKEY object but it would be possible.

What is the use case for this feature?