It is more or less universally assumed in practice that PQ key agreement algorithms will be paired with classical (RSA/ECC) cryptography. There's not much need to discuss or standardize it; it's a given.
That doesn't make much sense as an objection, since the classical cryptography code is better ironed out than the PQ stuff, and the logic to combine the two is fairly simple.
Unless there is an unexpected leap in the viability of quantum cryptanalysis, you should expect that all commercial/standard cryptography with PQ capabilities will run in a hybrid configuration.
I'm only commenting here because there's a pervasive belief that this is controversial in cryptography engineering circles, or that NIST is trying somehow to prevent hybrid schemes from happening, which is simply not the case --- though they may not bother to standardize any particular mechanism of combining ECC/RSA with PQ exchanges (but: they don't standardize stuff like TLS ciphersuites, either).
I suspect you do not understand given the phrasing.
Think of Tunneling or layers or nesting dolls. The order doesn't particularly matter from a security perspective. Though today I'd wrap with the conventional algorithm on the OUTSIDE layer, since it takes less computational time to check / validate. The inner layer would then be one or more of the post-quantum algorithms; a particularly paranoid application might use more than one if something absolutely must remain a secret.
It's like using different technologies to protect against nuclear waste leaking from storage. Each plausibly suitable layer of a different sort makes a leak less likely.
Post-quantum algorithms are, as yet, young and very possibly poorly understood. They may even offer no security at all (due to presently unseen flaws); therefore as a hedge against that include at least another currently in use and current best practice algorithm so that at least _that_ level of security is retained.
Plus, as I pointed out several replies ago, if the current (and fast since reasonable key size Elliptic Curve based) algorithm is the outer layer it can be validated quickly which is a better guard against denial of service attacks and other poor fakes.
A good Google search term is "CECPQ2". Roughly: run a PQ KX to reach a shared secret, and run an independent X25519 to reach a second share secret, and then HKDF them both (conceptually: just cat them together and use them as a single secret).
Why not just XOR them? Is the reason we use HKDF is so if one or both is only partially broken (only some bits or some correlation) instead of fully broken we still benefits from the information that is still there?
With an XOR, if you can control bits on one of the inputs, you can deterministically change one of the bits on the outputs. That is not the case with an HKDF.
Honestly, for all I know, they do XOR them. I didn't look carefully at how CECPQ2 works! Just: there's very straightforward joinery for running two key agreements and combining them so they both have to succeed to arrive at the session secret.
Later
(Leaving this comment here in perpetuity as evidence that I didn't think about your question as hard as David Adrian did. The message still holds, and that message is: "big ol' shrug".)
