This is a follow-up to HHH-13080.
There exists use cases where BasicCollectionMapper will have revisionTypeInId = true, namely when the collection element is an embeddable or a clob/blob. But as pointed out in HHH-13080, even collections that store entities could leverage having REVTYPE in the primary-key because certain ways the collection is modified can lead to situations where multiple revision types happen for the same entity within the same transaction if the two entity instances themselves are not reference equal.
What ultimately comes to mind is a situation where EntityA with ID 1 is removed from the collection and deleted while another EntityA with the same ID of 1 is persisted and added to the collection. The two instances are technically different but simply reuse the same identifier. With the temporary fix applied for 5.x in HHH-13080, this yields absolutely no collection change event but it really should.
With REVTYPE as part of the primary key, we can insert two rows into the middle entity collection table as follows
This change would then mean the use case presented in would change from generating absolutely no changes for the collection to inserting a series of DEL and ADD operations. While that may be less than ideal, I'd surmise the order of operations used by could be reworked to avoid that while our goal here extends support for corner case operations.