Storefront API: Combined Listing child products return inconsistent option data vs encodedVariantAvailability / Existence

We have identified a fundamental inconsistency in how Combined Listings are exposed through the Storefront API, which makes it impossible to reliably render product option pickers when querying a combined listing child product.

Observed behavior

When querying a combined listing child product via the Storefront API:

  1. product.options.optionValues

    • Returns only the option values that exist on the child product itself

    • The combined option universe (as defined by the parent) is not accessible

  2. encodedVariantExistence / encodedVariantAvailability

    • Appear to be calculated based on the combined listing parent option matrix

    • These encodings reference option values that are not present in product.options.optionValues

Why this is a problem

From Storefront API alone:

  • There is no standardized way to access the combined listing parent from a child product

  • There is no field indicating whether a product is a combined parent or child

  • There is no API contract that explains how options.optionValues should relate to encoded variant data

As a result, when using the Storefront API with a combined listing:

  • It is not possible to reconstruct the full option space

  • It is not possible to correctly interpret encodedVariantAvailability

  • Rendering an accurate option picker becomes impossible

Expected behavior (one of the following)

Any one of these would resolve the issue:

  • Child products expose a reference to their combined listing parent in Storefront API

  • options.optionValues on child products reflect the combined option universe

  • Encoded variant data is scoped strictly to the child product’s option set

Is this a known issue, and is there a roadmap or recommended pattern for safely handling combined listings via the Storefront API? We want to support 2k variants, so loading all variants is not an option.