The core team recently discussed the amendments proposed in this review thread:
We decided to accept the proposed amendment to remove randomElement as a customization point. randomElement remains as public API as a generic extension method on Collection. The core team was concerned about adding the other proposal's proposed randomIndex customization point as public API, due to the confusion it could sow and its potential for misuse, and considered having it as pseudo-private standard library API to be ineffective at the problem it's trying to solve, since it would at that point only be adoptable by standard library collection; if we only wanted to accommodate overlarge collections of a closed set of types like Range, we could do so with control flow within the randomElement implementation without a generalized customization point in the protocol. Many users expressed concerns about the fact that a generic implementation of randomElement would crash when invoked on a collection with more than Int.max elements, and the core team shares these concerns, but is willing to take a wait-and-see approach to see whether it warrants a response in practice. The trap on large Ranges and other collections can be addressed in the future in an ABI-compatible way by a number of means.