on whether that liquid snippet works: i dont think it can. component data for native bundles lives on the variant in the admin api (productVariantComponents), theres no product metafield mirror of it, so shopify–bundle.component_reference just comes back blank and the whole {% if %} renders nothing. no error either, which is exactly why it looks like a theme or caching problem when it isnt one.
liquid also cant tell you a product IS a bundle on the pdp. requires_components still isnt exposed on the variant object, thats been an open request since 2023.
two things that do work though.
in cart and order templates you already have the breakdown for free. line_item.item_components is a real property:
{% for c in item.item_components %}{{ c.quantity }}x {{ c.title }}{% endfor %}
zero setup, and it covers the “wait, whats actually in this” moment right before checkout.
for the pdp you have to mirror the data yourself, which is what paul is getting at. one json metafield on the bundle product, something like [{“handle”:“tee-black”,“qty”:2}], then all_products[row.handle] gives you the real title and image. what i would avoid is the two-parallel-lists version (one list of products, one list of quantities, paired by index), someone reorders that list in admin four months later and every quantity silently lands on the wrong product. shopify flow can keep the metafield in sync on product update so its not manual data entry.
one gotcha with all_products: component products that arent published to the online store come back empty, and hiding component products is pretty common. guard for it or you get blank rows.
disclosure, i build a bundle app (verve) so im biased here, but we render bundle contents from our own config instead of reading another apps namespace for exactly this reason. the second someone changes how they store it your section goes blank and theres nothing in the logs to tell you.