You cannot override the equality -operator but you can add simple short-named method "eq(anotherSet)" and perhaps variations of that.
It's not too much effort to create your own custom Set -subclass because it only needs to do what you need it to do that the built-in Set does not do. You can also perhaps find such an implementation on npm etc.
A perfect built-in Set would be great but being able to subclass the existing Set-class helps a lot already.
But my point is when you code an application you are not coding a library, but an app, so you only need to add the methods your app needs. You probably don't need to create an all-encompassing new Set-implementation that wins the library-of-the-year award. :-)
Maybe you just need to add a method named 'eq()'.
An added benefit of creating your own Set-subclass is you can put debugger-statements in its code to observe who uses it and how. You can put assertions in it to ensure only correct type of elements can be added to it etc.
I often used sets in Java as return-types or parameters to specify collections of unique items.
Profiling code over the years I noticed that, a lot of times the reason for a performance bottleneck was some hashcode calculation for a Set or Map.
So now I often use plain ol' ArrayLists.