建议将Selects单选和多选拆分为两个控件

[china-live]

1. 单选和多选在绝大多数据情况下是有明确应用场景的，几乎不会存在交换的情况。
2. 降低组件复杂度（开发/使用）。
3. 建议为Selects增加搜索/过滤功能，实际应用场景下，有时候列表会很长的（比如，选择同事时，你所在的单位有500人）。
4. 分别命名为Select和Selects

[doddgu]

多选只需要开启一个 Multiple 即可。已经非常简单了。
搜索/过滤是 AutoComplete和ComboBox的功能。AutoComplete已经提供，而ComboBox目前还没有。

[china-live]

我觉得拆分后定位更加清晰，而且能大幅降低组件的开发和维护的复杂度，因为无论是界面样式、业务逻辑，还是绑定的数据源上。
单选和多选都是不同的，揉在一起要做大量的判断还区别，有时属性之间设置值还会存在冲突。

[doddgu]

这个设计是从Vueitfy来的，如果Vuetify 3调整了这部分的逻辑我们或许可以跟进一下。当然这里其实跟组件结构有很大关系，select是基础组件，autocomplete和combobox都将继承它。如果所有衍生出来的组件也都需要支持多选也都要拆，那反而可能是噩梦。
其次，这个对于使用者是无感的。

[china-live]

AutoComplete 的搜索和值都在一个文本框，用户选择后原搜索关键字消失，在使用上有些细微区别，特别是在需要重新选择的时候感觉很难用。
如果Selects下拉内有个搜索框，用户可以保留自已的搜索关键字。

[china-live]

但是用户选择了呢

[china-live]

也就是，我选错了，要重新选一下

[doddgu]

也就是，我选错了，要重新选一下

不失去焦点前就没有问题。失去焦点表示已经确认。其实失去焦点再回来重新选择还要求保留上一次搜索结果，这种场景非常少见，我觉得是低频问题，组件本身并不需要过多的考虑这个情况。

[china-live]

这种二合一的输入框对年轻人来说容易理解，但我们做一个系统出来大多数时候并不只是给年轻人用的。很多时候，这些“设计”让不那么熟悉电脑，上了年纪的人来说很困惑。我们也是在被客户投诉很多次后，现场观察才发现这些问题。

[doddgu]

我们的组件提供了大量的插槽，在弹出层的Menu中你可以自定义一个过滤的框来二次筛选结果。但这属于定制行为，当然如果你愿意也可以提pr给我们。这类基于基础组件二开出来的组件我们叫预置组件，以P开头，与M和B开头的有明显区分。