The 13 contexts aren't 13 independent implementations — they cluster into a handful of actual runtimes, and the differences between contexts within a cluster are usually just which Smart Rules or layout options are exposed, not a different rendering engine. Product page, cart page, the two cart-drawer variants, cart popup, and storefront pages all share the same theme-app-block runtime and the same full capability set. Thank-you page and customer accounts share a runtime too, despite being grouped with post-purchase in the product's own UI — a grouping that's about where in the order lifecycle they sit, not about shared technical constraints. Checkout, checkout-header, and checkout-footer are three placements within one checkout extension. Post-purchase and POS are each genuinely their own thing, which is also why they're the two most constrained surfaces on the matrix below.
The pattern worth internalizing before reading the per-surface pages: capability drops as you move further past the point of purchase. Pre-purchase surfaces (product page through checkout) support the full behavior-mode and layout range. Post-purchase is the first drop — no auto-add or mix & match, since an order already exists. Thank-you and customer accounts drop swap and auto-add for the same reason, but keep mix & match and carousel layouts, which post-purchase's SDK doesn't support. POS is the floor: standard behavior only, no display or translation settings, because it's a staff-facing tile rather than a shopper-facing storefront surface.
The table below is the generated capability matrix. If a cell here ever disagrees with a specific surface page's text, the matrix is derived directly from the context configuration and should be treated as current; the prose pages are reviewed on a slower cycle.