Evaluating every key in every mapping pattern and checking them for duplicates every time a match block is entered would be prohibitively expensive, for negligible gain. The length check exists to avoid this step, replacing it with a much cheaper O(1) trapdoor.

Imagine the overhead of validating this match statement, for example:

https://github.com/brandtbucher/patmaperformance/blob/2fe8b79691d4f11b18d65b957ed36a85cb4761a4/bm_patma_holdem.py#L54-L95

> Consider if some other code is mutating the value of `A.a`. This could create some very strange and flaky bugs where the state of `A.a` can change and make the pattern invalid, but nonetheless not cause an exception until much later, or not at all.

That's okay with me; it's not the VM's job to check the runtime validity of branches that aren't taken.

> Another option if this problem is isolated to mapping patterns, we could introduce a new op-code: BUILD_MATCH_MAP, which is essentially a wrapper around BUILD_MAP that disallows duplicate key values.

I'm not sure what you mean by this. We don't call BUILD_MAP when evaluating mapping patterns... in fact, we don't build any dictionaries at all (except for collecting remaining items using **rest).

Unless others disagree, I'm probably going to close this as "not a bug".