Hi Fabien, thank you for answering but I don't agree in several points of your comments. 
> No, the previous solution did not worked perfectly.
It's a subjetive opinion. For most of our customers it did so... let's them decide what they need but Yes... of course, everything can be improved even if it's good enough. 

In v6.1:

>  - No clean solution to sell to persons rather than companies, but also: log a call with a person, assign an issue to a person, ...
Depending on what you consider a person. At the end a customer is a customer, someone/some company you are going to invoice to or receive invoice from. It doesn't matter so much if it's a company or person. For both of them we need in Spain only Name, VAT, address and fiscal data. Same for both. About relating an issue to a person, usually this person will be related to a company, so, if you set both fields partner_id + contact_id any situation can be solved. 

>  - No clean separation of concepts: partners and addresses --> but usually an address was a contact, not an address
Address was an address. Contact was a contact. What's the matter with that? 

>  - No clean address book: the res.partner object was designed for companies but users used it for a mix of individuals and companies due to how it was designed
Address book is Partner several addresses containing several contacts. Again. What's the matter with that? Why is so important think separating individuals and companies? Why should be different thing individual and company when you have got to invoice them. Even one individual could have several addresses and contacts related to him. What is the difference? Name field? I don't understand the point.

>  - Not easy enough: lambda users did not understood why they had to put a partner and an address on an invoice (and all others documents). I let you test proprietary accounting software, nearly all of them just have one field on the invoice: Customer. (and a lot of users did not even understood what's a partner --> they think it's related to partnership)
I don't believe it's so difficult understanding the concept. I sincerelly think that now, where everything is mixed, not having different concepts for partner, address and contacts, it's much more difficult trying to define with final users several complex structures. Before was much easier explaining any situation. I know that we will have problems as consultants explaining new aproach to most of our customers. 

 > - Not clean logic between all modules using the same objects (res.partner and res.partner.address) with different semantics: sale orders where designed to work with companies, events was designed to work with people
OK. This could be improved, you are right but it was not so complicated since you can relate any master data on any document clearly. Let's say delivery address, related to a partner address or CRM claim, related to a partner contact.  Both related to partner who created the document. Both fields are still needed, even on new aproach.

>  - base_contact was not good enough
As I said before, anything can be improved always but I was loving base_contact just like it was. Almost ANY complex situation, structure you could think about could be registered without any problem. You could have partner's principal contact data + contacts data on a working address with their function and even you could have personal contact data registered without generating duplicates, so... tell me only one complex structure that could not be registered on it. 

It's just a different way of watching same things. For me new aproach is a clear conceptual regression but I still think that it can be nice improvement having partners and contacts on same table if processes and domains are correctly defined. Anyway, I say again partner_id (mandatory), contact_id (only mandatory on several objects) are needed all around the aplication. Otherways no reports, no processes will go right. IMHO.

Thank you very much for your attention.
Ana