I've been taking a considerable amount of time reading almost every single message of this thread, so I'd had no time left to express an opinion, but here it is: I believe both solutions stink, and that's the reason of this blocking situation. Now, I dont have any instant miracle solution so if you don't want to lose any more time with this flamewar, you can stop reading my post just now. Feel free to tell me if I didn't understand some point and I apologize if so.

OpenERP S.A.'s solution is obviously and largely questionnable but it makes sense. OpenERP SA has clearly not anticipated all the consequences of the semantic move, but the community (I'm part of it) seems to really discover or understand this move only these days, and refuses it. So everyone here seems to be right.

Why I don't like partner_id + contact_id :

I really don't like company data duplication in the contacts. I don't like the impact of the community modules. But I don't like the split between contact and partner either, because it's a denial of the fact that even if contact_id field is added, all the partner_id fields in the wild will still be able to represent a contact as well.  As a consequence, we won't be able to chose between partner_id and contact_id.  In my opinion, the problem is absolutely not solved by adding a contact_id field, because the semantic lies in the res.partner model, not in the name of the field "partner_id" : the partner_id field always points to a res.partner model, which will always represent either a contact or a company anyway. Adding a contact_id doesn't change this fact.
The partner_id + contact_id solution really need more, it would require to split back again the contacts and the companies so that the partner_id field is guaranteed to always be a company. And that would break the b2c possibilities. The res.partner model can be a partner or a contact, this is too late to revert this idea. Adding a contact_id doesn't hurt, but it will never prevent the partner_id from being a contact as well. So what happens if we have a contact in both fields ?  This can be prevented with onchange but it means that the datamodel is not consistent and depends on the UI and the javascript. This would allow to write anything though xmlrpc and lead to inconsistencies, or duplicate the onchange behaviour in the xmlrpc dialog.  Adding a commercial_entity_id does not hurt and it can be guaranteed to always be a company, since it does not point directly to the res.partner model, but is a function instead. So I'll never have two contacts in partner_id and commercial_entity_id : either two companies, or a company and a contact. So in this case there is no semantic change. The semantic change has already happened, and it lies in the res.partner model. Not in the partner_id field.

Why I don't like partner_id + commercial_entity_id :

The original idea was to invoice either an individual or a company. So the partner_id field would require to be either a an individual (= a contact) or a company. So ok, let's put everything in the same model. This point seems accepted by most people now, but I'm not sure it was a good idea. Putting things in the same model or the same table is not the definitive solution to allow companies *and* individuals to be invoiced, it could be possible with a real object paradigm, with real APIs and real object *interfaces*, so that contacts and companies would live in different tables and different models, but both could be invoiced, for example through an IInvoicable interface, which could be provided by object adapters on the (distinct) Contact and Partner objects. It's definitely possible in Python, but that's a different topic...
So ok, a partner object can be a company or an individual, that's fundamentally wrong but it's too late now, and since the partner_id field is a res.partner, it can be a contact, and now the only possible way to make it work and be consistent is to consider that the contact *is* the company. It's a representative. Thus leading to this insane data copy from the company to the contact. I hate it. It makes the framework too opinionated, and doesn't leave much space for integrators to change the semantic or the magic, since other (non-community) modules rely on this logic and magic.

Actually the real game consists in localizing where the real meaning of "contact" is implemented. Raphael and others wants to set it in the field names and the views, while OpenERP wants to put it in the res.partner model code itself.  In the former we depend too much on the views and the javascript code and we lose the intended semantic of the partner_id, but in the latter the data model becomes too semantically opinionated and contains too much forced choices.  Nobody cares if these choices are done in some modules, but the partner concept is a central part of the framework, so everyone cares.

Yesterday at anybox we had a customer in a training that was telling us the change in the datamodel was just shoking, and will probably pay us to change the datamodel to something that is closer to what he's used to: split contacts and companies. That's a pity because it will be much more difficult to implement other modules with a different partner model. I think we are facing a problem in the framework, which does not cleanly separate the business logic and the low level data storage. I remember a blog post from an indian openerp developer complaining exactly about this problem...