At this point anyone who wants to approach this task needs to resolve the issues brought up previously on page 4 regarding the level of desired synchronization. In addition, there needs to be a map developed between the profile data elements in WP and the profile data elements in BP defining where the synchronization occurs at a detail level? These can both become somewhat nasty tasks.
Another alternative is to ignore the WP profile as much as possible and make maximal use of the BP facilities for profile management. Any desired elements that are part of a WP profile can be re-created and maintained as BP elements. Synchronization is not an issue if no one ever looks at or uses the WP profile. (The critical elements that exist in the shared users table will be maintained by BP as a natural course of work.) Not ideal, but it wouldn’t be the first time someone hid unused old code in a dark closet that was never visited.
The ideal approach from my perspective would be for the lead developer teams of WordPress and BuddyPress to agree to merge the core profile functionality of both systems into a single set of shared tables and functions. Normalization of data and function is usually the best approach for usability and maintainability.
For anyone interested in performing synchronization of the two existing systems there are more tools that can be brought to bear in solving the problem. The action hooks now employed by the BP xprofile functions shown above are not the only hooks available for use. I would highly recommend a full review of the action hooks and filters in the WP Codex, and the BuddyPress Codex Action Reference for the Extended Profiles feature. In some cases, rather than creating and maintaining duplicate data, you might use these hooks to display or use data from one side of the system for a function or screen on the other side. Eliminating the data redundancy and the maintenance problem might be a better move than trying to manage synchronization later.