A simple test case:

ONLY(Group_RemoveIntPrimaryKey)
{
    Group g;
    TableRef table = g.add_table_with_primary_key("class_foo", type_Int, "primary", true);
    table->create_object_with_primary_key({0});
    table->set_primary_key_column(ColKey{});
    table->create_object(); // throws realm::KeyAlreadyUsed
}

After removing the PK, the table's sequence number is zero and the next object created will try to use a key of zero, which is already taken. This also happens with non-zero PKs; if the object created had a PK of 3 then the fourth object created after removing the PK would break. String primary keys might have the same problem, but it'd be harder to hit it. If they do, this'd need to be fixed in both v10 and master, but the int version only breaks in v10. There shouldn't be a related issue with adding a primary key as that rebuilds the table.

A few ideas for fixing it:

1. Regenerate the object keys for all objects when the PK column is removed. Breaks the current object store logic for handling PK modifications inside migrations (which removes the PK column, makes the change, then re-adds the PK column at the end of the migration).
2. Handle collisions when allocating an ObjectKey (in allocate_sequence_number() or allocate_object_id_squeezed()?) and generate a new one if so. Has a performance impact even in the normal case where a collision can't happen, but probably trivial compared to the cost of allocating an object?
3. Set the sequence number to table.maximum_int(old_pk_column) + 1 when removing the pk. Probably doesn't actually work?

This is currently blocking merging objectstore master into v10.