A few months ago I was working on upgrading my companies d6 sites to d7 before some time sensitive projects took priority. Part of that upgrade process was replicating our current solr driven product catalog in d7.

For starters, there is this module http://drupal.org/project/apachesolr_commerce. However you will need to apply all the patches in the issue queue for it to work.

Then, I created an extra module located here: https://github.com/mwisner/apachesolr_commerce_extra. Note: this is really just a test bed for me. After I had finished off some of the features I was going to supply patches back to the apachesolr_commerce module. I would not install it unless you are ready to dig into the code and play around.

Basically, I was running into the same issues as you. I opted to go with indexing and displaying the "product display" instead of the actual product entity. However I do not know if this is the 'correct' route.

Then, I created a solr field that indexed the product references. Using this referenced data I loaded the product info, such as the add to cart form, during the catalog rendering. Without doing any real research, I think this is kind of a fail for performance because you still have to load all the product entities.

All of the sorting and facet information I pushed up to the product display. For instance that apachesolr_commerce_extra module should have two different "best seller" sorting options as well as a "price" sorting option. during solr indexing this information is calculated and stored with the display.

Issues that I came across so far:
-- The relationship between product and product displays is many-to-one. So if you want to go with sorting pricing information on the display so you can sort the displays by price, which price do you use? The avg between them all? I doubt that is an acceptable solution for most people. Best sellers are a little more giving, you can simply sum up the values for each product and it would end up providing a semi-accurate value for a given product display.

-- What about facet sorting on fields that are specific to the product? ex... color? This issue made me start thinking that perhaps instead of loading the product entities during display we should go the other way around... use the product entity as the primary source of information and then load the display during presentation. This approach has a number of issues as well... For example how to merge products under one display, and how does that effect pagination?

-- You can't join two solr documents during a query. I did a little research and found that you can join solr documents during a query with some sort of solr addon. If we could get document joins in solr then you could simply store the data correctly and use a join to join the product display with the product entity.

How far I made it: I ended up having a semi-usable product catalog with add to cart buttons and facet sorting on the node display.

Any luck on adding Commerce Product fields to the SOLR index? I also want to add a price facet to my product catalog generated with Drupal Commerce and Apache SOLR but I can't seem to find any tutorial on how to do it...
Is the apachesolr_commerce module the way to go for these things?

I use the Commerce Search API module and for simple commerce sites it is working properly.
BUT if I would like my product prices to change depending on user role I have a few problems.
My use case is the following:
I have a webshop where products are displayed through a search index view. My product prices need to depend on user role. If no price for the specific user role is available then the original price is used.
I can switch the prices with a price-calculation role. .That's all working perfectly. But with the search index view I see a few problems:

1. Make the price range slider use the correct price (a product has 3 prices depending on user role)
2. Make the search api sort facet use the correct price (what if price can also be original price?)

I can't seem to figure out how to do this...