IIUC, the optimization indicates the ordinal that was changed; it doesn't indicate which value was deleted. You would have to look at the previous revisions to to find out which value got deleted.
This is just an observation. I'm not sure if it indicates a problem.

I don't think it indicates a problem from Envers point of view; however, it certainly may from user code that might be trying to interpret the audit row entries for business use cases.

Would introducing the optimization cause any complication with existing data? In other words, could Envers deal with both optimized and non-optimized collection audit tables?

No it wouldn't, although if such optimization were to be implemented I'd probably suggest a configuration toggle so that users could keep audit data consistent if they needed. But overall, this optimization doesn't affect any Envers functionality but could have an impact how users interpret and use the audit rows in their business code.

For now, I'll leave it as-is and just address the underlying comparison issue.