Unpredictable behavior when a Contact has more than one membership for an organization

This is a follow-up to the discussion at http://issues.civicrm.org/jira/browse/CRM-10068 .

The issue seems to have arisen as a result of http://issues.civicrm.org/jira/browse/CRM-7297 .

During the implementation of "Membership Upselling," a new assumption was added to CiviCRM that a contact will only have one membership record per organization. In fact, CiviCRM does not enforce this assumption; both the administrative GUI and the API can be used to create an unlimited number of Memberships per contact per organization. When this occurs, the resulting behavior of the system is unpredictable and undocumented (i.e., the system does not provide warning messages about the unsupported configuration).

Besides the issues mentioned in the comments of the above ticket, I have observed the following:

A user registers for a membership, which triggers a condition that causes API code to create a second Membership record, with an explicit end date. Instead of maintaining 2 membership records with their individual end dates, CiviCRM overwrites the first membership and extends it's end date by one year. (I suspect this happens as a result of the creation of the MembershipPayment Record, but I have yet to confirm.)

Other inconsistencies arise where the system behaves differently depending on whether a Membership is created immediately (due to real-time payment) or at a later time (due to pay-later, when an admin marks the Payment complete). I don't have these effects well documented, but I am willing to do further research if it would be helpful. I suspect this is only reproducible when using certain hooks to respond to the creation of a Membership.

As I see it, there are two possible solutions:

1.) Prevent the system from ever creating more than one membership per contact per organization. (e.g., add a column to civicrm_membership fro organization_contact_id and create a unique key on that + contact_id). This is not ideal because it removes from the system functionality it previously allowed, but it at least prevent the introduction of new data inconsistency.

2.) Require all operations on Membership and MembershipPayment records to contain an explicit Membership ID, so that it is impossible for the system to overwrite the 'wrong' record when multiple memberships are intentional. The system should never try to calculate which Membership to act on, but should require the Membership ID parameter to be specified, and should throw an exception when it is not. (I suspect the primary case where this is not done is upon create of MembershipPayment records. )

Ideally, the GUI should never remove or update a Membership without prompting the user for confirmation when a contact has more than one membership per organization. (Perhaps the DAO could require a 'confirmed' property to be true before an UPDATE or DELETE operation is run against a membership?) But this may not be strictly necessary to prevent the kinds of errors that can now occur.