distinctKeysAddressDistinctEntries

Distinct keys address distinct entries. Writing one must never change another.

StoreKey's own KDoc says it exists "so that callers cannot accidentally mix up keys", and DurableStore describes itself as key-addressed with no restriction whatsoever on what a key may contain. A backend that folds two distinct keys onto one entry does not merely confuse them — the second write destroys the first value, silently, with no listing surface for the caller to notice it through.

The key set is chosen against the shape three of the four in-tree backends have: a key mapped onto a filesystem path or an IndexedDB key. So it walks the characters a filename sanitiser reaches for first — ., /, space, : — beside the two an [a-zA-Z0-9_-] allowlist keeps. Every pair differs somewhere a lossy sanitiser folds, and nowhere else: same length, same letters, one character apart.

The non-ASCII pair is the same argument one step further out. Two sanitisers that both look correct disagree completely on it — a Regex("[^a-zA-Z0-9_-]") replacement folds every non-Latin letter to _, while a Char.isLetterOrDigit() test keeps them, because isLetterOrDigit is true for Cyrillic. Keys derived from anything a person typed reach this.

The case pair, and what a green on it does not prove

a-b and a-B are the pair whose absence let the #2506 defect survive longest on the file backends: every sanitiser in the tree passed a letter through unchanged, so the two keys were distinct strings and one file. Nobody wrote the pair, so nobody measured it.

It is worth stating here rather than only in each file backend's own tests, because there are two ways to fail it and only one of them is about filesystems:

• A backend that folds case itself — a lowercase() on the way to a filename, an IndexedDB key normalised before it is stored — fails this everywhere, on every target and every filesystem. That is the failure this suite genuinely establishes the absence of, and it is reachable by any backend, file-backed or not.

• A backend that hands both keys to a case-insensitive filesystem fails it only where the filesystem folds: APFS by default, exFAT, NTFS — but not ext4. So a green on a Linux runner is no evidence at all about that second failure, and must not be read as any. Only a run on a case-folding filesystem discriminates, which is exactly why the defect went unmeasured: the CI most projects run cannot see it.

Stated the other way round: this property is unconditional about the store's own behaviour and conditional about its medium's. It is kept here anyway because the first failure is the one a new backend is most likely to introduce, and because the pair costs one entry.

Each key gets a distinct one-byte value and every one is read back, so the failure names which keys collided rather than only that something did.