Hello everybody and thanks for all these ideas, requests and suggestions.
One important thing to understand is the original spirit of store, how it will evolve, and how this relates to the points beeing discussed here.
The very original and clever idea of store, as it was developped by its creators and successive developpers, is its architecture ; among others : templates and providers.
The concept of providers has not been developed to its full extend yet, but the the early developpers have shown the way.
If we had a real , 'article provider', store would mainly be a 'core store' with a simple 'default product provider'. In such an ideal scenario, any of you guys might develop his own article provider, that would exactly match his needs. We might have an eco-system with several 'store article providers', some of them free and others at a cost.
Same is true for payment providers, etc. We expected that anyone might offer his own bank payment provider, but unfortunately the provider logic is not implemented in a way that permits to reach this goal immediately.
But the drawback of all this is that the core should not implement in itself any specific features that must belong to the provider. The more we try to hardcode inside the core, the more difficult we make it for other developpers to develop their own providers that will interface nicely with the core module.
To put it another way, if we include to many tables / properties in the module's database structure, we make it harder for others to design their own architecture, and to communicate with us. Thus we would we go away the idea of a 'provider' - i.e. separation beetweeen the shop and the products.
The team which has Store in charge for the current period would not want to destroy the original 'onion structure' (concentric and modular) of store. We believe that store should offer a framework to other developpers to plug in their own providers, rather than a 'one size fits them all' keyhand solution for every need.
That said, colours and sizes are a must, I agree with that 
. So let's see what we can do !
Your comments welcome on this provider pattern discussion, and how you would compromise beetween re-inforcing the provider pattern, versus bringing immediate solutions in.