When designing the catalog, the first thing is to understand what is your variant. Basically, it is one sellable item with concrete color/size or other properties.

Next thing I am looking at is how to group these variants. For this purpose, you should use products in multiple levels. In 90% scenarios, you have just a product -> variant grouping where you use a product to group variants by size for example. In more complex scenarios, you can have multiple levels of product groupings. In one project I have used a product -> product -> variant grouping. As I remember the first product was a size and the second one was a color.

And the rest is rendering logic. You can have a separate page for each variation and render color/size selection there with links to other variations. Or you could have a common product page and load variants by ajax.

Now you mention that you only have a couple of thousand of variants, but I would still like to point this out: If your render logic requires data from multiple/many variants, you should consider alternate methods for loading this data other than pulling all the variants straight from the content repository. Sure, you can batch load them and they will be cached, but if the catalog is big enough and visitors hit enough different products you risk a steep decline in cache hit ratio because the cache is constantly trimmed. One way of doing it is to index these variant values together with the product, and render them directly from the index document.

Another way could be to cache these values as a separate (smaller) model object. The default cache implementation trims the least used items (all other things equal), so if you compose and cache a smaller model and from then on use that when rendering, the larger variant content object should be preferred for removal by the trimming algorithm (unless used frequently elsewhere of course).

I don't know the details of the quicksilver modeling and implementation off the top of my head, I'll see if I can get someone else to give some more details about the reasoning behind that.

I think we might be mixing things up a bit here. Although present in FashionProduct, AvailableSizes and AvailableColors is not actually used in Quicksilver so you can safely ignore them.

If you check CatalogEntryViewModelFactory (which is called from ProductController), it builds a list of SelectListItem populated with the available colors and sizes. Those two lists are then used in the view to render the options.

As Magnus points out, it is a good approach is to index the variant values to make the solution performant. This is generally used in searching and filtering.

When it comes to availability, this is something that is generally checked twice: first time is when you try to add it to the cart. If you already then know that there is no stock, you ususally disable the "add to cart" button, or give the user a message. Or you can already in the dropdown indicate that it is out of stock. Second time it is checked is during checkout, since the availability can change between the add and checkout.

As for specfic product/variant types it depends on the case I'd say. But in general we try to avoid having distinct types for all kinds of product (types), but rather stick to one or a few general types. In Quicksilver this corresponds to FashionProduct and FashionVariant. You can have the common attributes like code, name, brand etc. as typed properties while the specific attributes like wattage, material, battery etc. can just be key values in the Property collection.

My colleague, Maris have some fair points. The key is to identify what is your variant and the next is to determine how you want to render the products. I have worked both with 3 level (product-product-variant) and 2 level structures. 

Having a separate render for the variant depends on the product type: it makes sense for a furniture (a black chair), but not for a green jacket that exists in 10 sizes. For clothes I prefer a product page where you use ajax to load variants (select size).