Sets and maps should have an extra key option to extract keys from objects, to generalize lookup in case of non-unique objects and such. It'd also be useful for typed sets to ensure their values are coerced appropriately, and implementations could special-case sets with key set to Number, BigInt, String, and similar eagerly. (In particular, BigInt sets don't actually need to store bigints internally for smaller values - they can just use a sparse bit set and upgrade only when they encounter a value too large to fit.) This would be purely internal, never exposed.
Also, if WebIDL interfaces with the setlike<T> declaration are ever to be converted to native Set subclasses, this functionality would be required for them as they'd 1. need to validate keys and 2. in many cases apply coercions (like key: String) to them. And yes, this would be the minimal functionality required AFAICT as no platform object I'm aware of contains a setlike<T> declaration and the only other restriction, that it needs to implement the interface directly, is something I strongly doubt would be necessary to keep.