SQL describing cohort problems after django 1.8 upgrade, and short term fix

cohort_problems_sql.txt

What's going on:
    -Users are not being removed from their course_groups_courseusergroup_user records when they should be
    -CohortMemberships are working fine

Evidence:
    -there are 34 affected users:
        mysql> SELECT user_id FROM course_groups_courseusergroup_users WHERE ( courseusergroup_id, user_id ) NOT IN (SELECT course_user_group_id, user_id FROM course_groups_cohortmembership);
        "show me all the users who appear to have an old-style memebrship record that is not tracked by a corresponding new-style record"
        +---------+
        | user_id |
        +---------+
        <removed since this gist is public, I have this info recorded>
        +---------+
        34 rows in set (0.54 sec)
        -note that the inverse of this, "show me cohortmembership entries not recorded in course_groups_courseusergroup_users" yielded an empty results set

    -Of these 34 bad cases, all have at least *some* entry in the cohortmemberships table:
        mysql> SELECT * FROM course_groups_courseusergroup_users old RIGHT JOIN course_groups_cohortmembership new ON old.user_id = new.user_id WHERE (courseusergroup_id, old.user_id) NOT IN (SELECT course_user_group_id, user_id from course_groups_cohortmembership) ORDER BY courseusergroup_id;
        "show me the old, and a best guess at the corresponding new, style records for memberships that appear in the old dydtem but not the new.
        +--------+--------------------+---------+--------+----------------------+---------+-------------------------------------------------+
        | id     | courseusergroup_id | user_id | id     | course_user_group_id | user_id | course_id                                       |
        +--------+--------------------+---------+--------+----------------------+---------+-------------------------------------------------+
        <removed since this gist is public, I have this info recorded>
        +--------+--------------------+---------+--------+----------------------+---------+-------------------------------------------------+
        38 rows in set (4.57 sec)
        -note that there are 4 extra rows here - these correspond to cohort groups in other courses for affected users. There are 4 such cases, so nothing unaccounted for.
          -users can be in multiple courses, each of which uses cohorts. This is fine, it is not a problem at all.
        -also note that for the 34 "interesting" rows, there is always a *different* course_user_group_id from the new cohortmembership table.

    -Finally, the proof that every user involved in this discussion got here by way of having a membership move event fail:
        mysql> SELECT * FROM course_groups_courseusergroup_users WHERE user_id IN (SELECT user_id FROM course_groups_courseusergroup_users WHERE ( courseusergroup_id, user_id ) NOT IN (SELECT course_user_group_id, user_id FROM course_groups_cohortmembership));
        "show me all the old-style membership records for users in this list"
        +--------+--------------------+---------+
        | id     | courseusergroup_id | user_id |
        +--------+--------------------+---------+
        <removed since this gist is public, I have this info recorded>
        +--------+--------------------+---------+
        72 rows in set (0.66 sec)
        -Note that there are 2 "old-style" entries for each of the 34 affected users (=68, add the 4 "other course" rows to get the total of 72)
    
    -For at least one user, the event logs support cohortmembership as having the right information for a user:
        -event log sent to me by Olga
        -clearly see 3 events - add, remove and add. New system agrees with this, old system did not catch "remove" and did "add" twice

Solution:
    -just clean up SQL tables!
    -Items to be deleted can be shown as:
        mysql> SELECT * FROM course_groups_courseusergroup_users WHERE ( courseusergroup_id, user_id ) NOT IN (SELECT course_user_group_id, user_id FROM course_groups_cohortmembership);
        +--------+--------------------+---------+
        | id     | courseusergroup_id | user_id |
        +--------+--------------------+---------+
        <removed since this gist is public, I have this info recorded>
        +--------+--------------------+---------+
        34 rows in set (0.72 sec)

-Unproven:
    -fixing the database will close this hole forever
        -there were 32 entries earlier today, and 34 now. Is there something strange with this course's settings? How does that related to the sjango 1.8 upgrade?
    -why is this happening at all?