This is a partial transcript of a conversation mostly between mfer and myself in IRC today. The topic of discussion was tricky display issues for products now that we have implemented products as completely separate from product display. In other words... you define a product in the back-end, but to present it for sale to the end user you'd need a product display node type that includes a product reference field. The problem with the reference field is if the formatter is an Add to Cart form (the track I've been taking), how can it pull in extra product data like images for display on other parts of the node? Or should images simply be attached to the node on display? The problem with that is we need to be able to present a thumbnail image on the shopping cart page. And then throwing into the mix products that don't have node displays at all, where will the display data come from once they're in the cart?

My hunch is that when an item is added to the cart, we would at that time specify some sort of context information that we can later use to populate the product's title, cart image, and price. The problem is we've always loaded that information on the fly for items that are simply in the shopping cart, because if the product is updated between the time the user adds it to his or her cart and actually proceeds to checkout, we wanted it to have the latest data.

Anyways... more questions than answers here, and plenty to talk about next week in Paris. The transcript follows with names when a dialog has been preserved:

the idea of attributes as they exist in Ubercart will be nearly obliterated; instead you'd attach a field to the product type and specify one of the options at the point of product entry, thereby enforcing 1 SKU per product variation

the add to cart form itself will introduce the magic sauce necessary to boil all referenced products into appropriate selection fields based on the fields on the products

the big thing is until now, we haven't considered displaying a product view page directly to customers; customers would instead look at product displays that referenced the admin defined products...

mfer: when a product is displayed does it have anything to do with nodes?
rszrama: to the end user, yes; administrators add products in the back-end and display them to end users through nodes w/ product reference fields

the idea is a "Product" is the item in your warehouse... the "Product display" is the product on a shelf in your store
you might display the milk in the dairy section and in a smaller cooler at the front of the store, but in the warehouse, it's all on one shelf
you might also bundle the milk with chocolate syrup because you're awesome
(this is all D7; in Ubercart, we combined the ideas but never clearly defined what a product was)
so, you define products through admin/commerce/products/add/[type]
for product displays, you'd have to define a node type w/ a product reference field

so, the full workflow might be like:
1) Create a t-shirt product type with a size field.
2) List a bunch of different styles of shirts at various sizes, each having a unique SKU.
3) Create a product display node type that has a product reference field.
4) Create a product display node for each style of shirt and reference the products representing the various sizes of that style.
5) On each of the product display nodes, I'd use the "Add to Cart form" formatter for the product reference field and expect to see an Add to Cart form with a select list letting me specify the "Size" based on the different products I'd referenced.

the idea here is we'll have a much better defined set of products... and if we ever needed to change the SKU of what is actually sold to an end user, we can add a new product and update the product reference from the display node without disrupting all our past orders / records
and we could also use the same SKU across multiple sites or use cart links to sell the products without ever displaying them on a product display node if we wanted

mfer: but, then you have an image of the shirt on the product. how do you get that to the node to be displayed?
rszrama: exactly… so, I think my train of thought thus far has been the image would be on the product display node, but that's not helpful if I want to add the item to the cart with an image without ever creating a product display node

so I'm really ambivalent at the moment... that's basically the question of the hour
where does the image come from?
and for that matter, where does the product title come from that gets displayed in the cart?

mfer: from a grouping standpoint i'd want all the product details on the product itself... then if you want to change them you'd do it on the display node
rszrama: meaning have an ImageField on the product that somehow can be displayed through the node or else overridden at the node level?
mfer: so, you'd have the product images available on the entities. then, if you wanted a picture of say milk and chocolate syrup you'd use that on the display. but, if you wanted to use an out of the box image of the milk you could use that too

I think that's the easiest way to have product images that end up in the shopping cart w/o ever having to list a product display node
I just don't know what the technical implementation should be for complex product references; i.e. it's simple enough for a product display node w/ a single referenced product
but what if the selectable attribute is color and I have a unique image for each one? although, maybe that would be even easier...
if we have that data stored with the product, we can get it when the product display node is loaded via the product reference, but how do we then turn it into extra elements that can be moved about in the display node's template... maybe that's a simple hook_node_load() / _view() in the product reference module?