Perhaps. So you're proposing to have this as a regular built-in type? It's hard for me to judge how popular this feature would be, but I guess people often use arrays while they actually want set semantics ...
Perspective from a potential user: I'm currently working on something where an array-like structure with fast membership test performance would be very useful. The main type of query is doing an =ANY(the set) filter, where the set could contain anywhere from very few to thousands of entries (ints in our case). So we'd want the same index usage as =ANY(array) but would like faster row checking than we get with an array when other indexes are used.
Our app runs connecting to either an embedded postgres database that we control or an external one controlled by customers - this is typically RDS or some other cloud vendor's DB. Having such a type as a separate extension would make it unusable for us until all relevant cloud vendors decided that it was popular enough to include - something that may never happen, or even if it did, now any time soon.
