Inconsistency with hook_pre and hook_custom for custom fields

There is a serious inconsistency in how hooks are managed for custom fields.

If a custom group has an 'Inline' display type, the fields are displayed on the main contact page, and the hook_pre and hook_post are called during create/edit operations. Since all the context in provided in these hooks, the code for dealing with these custom field is simply a variable read or assignment.

If you then change this custom group to a 'Tab' display type, the fields are now displayed in a tab, and the hook_pre and hook_post are no longer called during create/edit operations. Instead, there is a totally strange hook_custom that is called without any context and independently for each field in the group. Code for having a calculated custom field is then a lot more complex since you have to call core functions to get table/field names, then construct SQL queries to read any context in the database and read/save the custom fields.

This inconsistency seriously complicates any code having to deal with custom fields - whether this is to calculate the value of a custom field, sync these fields with an external database, or in any other use case. What is a one-liner exercise if the custom group is displayed inline turns into an obscure piece of code if the same field is displayed in a tab - and you need to keep both in case the customer changes his mind as to how the field needs to be displayed.

Maybe we could align how the hooks called for custom fields with the way we are processing hooks for all other contact-related information:

• on a contact create/edit (main page), call hook_pre for the contact with all related information in sub-arrays (addresses, phones, emails ... and custom group/fields), then call hook_pre for each related information (address, phone, email ... and custom group/fields)
• on a tab edit, call hook_pre for the custom group/fields that were changed in the tab. Note this would equally apply for multiple-records custom group/fields.