[Bug]: RemoveKey loses entry identity for equal values and produces invalid list indexes

[dwcullop]

Please note we can't commit to any timeline.

Describe the bug 🐞

Index-free list changes cannot distinguish different cache keys whose values compare equal, or keys sharing the same object. The new filter fallback selects the first equality match. Refreshing another key can retain an excluded item or update the wrong position. Unindexed update/remove paths also fail list validation/filtering.

Step to reproduce

Create two distinct cache keys with comparer-equal values. Include only the second value in source.Connect().RemoveKey().Filter(predicate), exclude that value, and refresh its key. Also exercise shared references, custom-equal structs, updates, removals and indexed moves.

Regression tests/checks:

EqualValuesAreRefreshed_FilterRemovesTheChangedKey; SharedReferenceIsRefreshed_FilterTracksEachKeySeparately; EqualValueTypesAreRefreshed_FilterRemovesTheChangedKey; EqualValuesAreUpdated_OnlyTheChangedKeyIsReplaced; EqualValuesAreRemoved_OnlyTheChangedKeyIsRemoved; IndexedMovesAndUpdates_KeepEqualValuesAtTheirKeyedPositions

Reproduction repository

https://github.com/reactivemarbles/DynamicData/tree/85ee49cfd54d8782c36ed137886d318e942345c4

Regression tests and fixes:
https://github.com/reactivemarbles/DynamicData/tree/u/dacullop/main/pr-1165-review

Expected behavior

Discarding keys must retain enough positional identity for each logical entry to be changed independently. No excluded entry, unrelated replacement, invalid index, or error should remain.

Screenshots 🖼️

N/A.

IDE

N/A; command-line reproduction.

Operating system

Windows.

Version

.NET SDK 10.0.401; net9.0 test target.

Device

N/A.

DynamicData Version

Main 10.0-preview at 85ee49c. The related 9.5 candidate is PR #1165 at 3d76872.

Additional information ℹ️

Repository tests retain excluded entries, select the wrong key, reject negative replacement indexes, or report ArgumentOutOfRangeException on updates/removals. Related to #1119, but the equality fallback additionally turns an exception into silent wrong results.

[JakenVeina]

I don't really see this as a defect. Caches aren't sorted, they're indexed by key, so when you drop keys, what else would you expect but that duplicate items can no longer be uniquely identified, and the resulting ordering is arbitrary?

Also...

keys sharing the same object

This is kinda not really a supported thing in cache-land. Caches don't let you supply different keys for the same item. You can end up there on account of transforms, but that's not really what caches are "for".

And what PR is this supposed to be fixing? Our 9.5 candidate didn't touch the .RemoveKey() operator.