Q:

Class structure of Product, ProductBundle and "Purchased" versions of them

I have an existing pair of business object types, Product and PurchasedProduct, the latter being a subclass of the former.
The former represents an object in the customer's shopping basket, with all information (except quantity) being read from an "archetypal" product stored in the database.
When a customer checks out, the contents of the basket are stored in the database with the ID of their archetype, but with all the relevant potentially-variable purchasing information (net price, VAT rate, quantity, etc) "baked" into the record. This is so that when a customer checks their order history, each order will create a PurchasedProduct object that will report the at-checkout values, rather than the archetypal values.
Thus, when retrieving a purchased product instance, the archetype can be read first to fill in the majority of data (because a PurchasedProduct is-a Product), then the purchased instance is read to fill in the at-checkout values.
Now the client wishes to have product "bundles". These act in all ways identically to a singular 'Product', except the following:
1) A bundle contains a list of Product objects (with fixed quantities), but will have its own price unrelated to the contained products, its own quantity, etc.
2) When purchased, it not only needs to record its own checkout-time price etc., but that of its constituent products
My initial thinking was to have:
ProductBundle : Product
{
    public List<Product> Products { get; set; }
    // other stuff as needed
}

PurchasedProductBundle : PurchasedProduct
{
    public List<PurchasedProduct> Products { get; set; }
    // other stuff as needed
}

That would seem to add a lot of complexity to the ProductRepository whose responsibility is mainly converting product IDs into business objects. It would need to check the incoming data and switch between several paths for each of those four types, where some paths have duplicated functionality. It also seems to duplicate the list-of-sub-products property. Finally, a PurchasedProductBundle is both a ProductBundle and a PurchasedProduct, but C# doesn't have multiple inheritance, of course.
An alternative route might be composition, so a ProductBundle is a composition of a single Product and a list of Products, but that seems like a lot of boilerplate to pass property access through the underlying Product.
Are either of these a sensible route, or is there some really neat pattern I'm missing?

A:

One possibility is to consider a PurchasedProduct not to be "derived from a Product". But rather have the IProduct interface, which is either a PurchasedProduct or Product.
Your product bundles would be IProductBundle (which are IProduct), and provide IEnumerable<IProduct> Products { get; set; }, for both the PurchasedProductBundle and ProductBundle.
The reason behind that is that a PurchasedProduct is not a Product, it is much more a Purchase or OrderLine than a Product, and many reasons may apply to change the price, not only the fact that prices will evolve with time, there could be a commercial offer, a coupon.
Another possibility is to consider that you do not mind at all what are the prices of the products included in a bundle? after all you'll probably advertise the rebate percentage globally, but it is another question.

