Pinging @Ichoran and @joshlemer here. Echoing comments from earlier, specifically

On the other hand, I'm a little surprised at the results for VectorMap, so it may be that VectorMap can be sped up substantially. In that case, if you ask me which architecture seems more promising, Vector + Hash vs. IntHash + Hash, I'd think the former. While Vector isn't great at removals, it's also not that common for immutable collections to have a lot of single-element removals, and in other cases the Vector architecture ought to be better than the custom IntMap. Otherwise, why don't we throw away Vector and replace it with an IntMap?

Don't have an issue with changing the default however there are some suspicious results about the benchmarks (furthermore there are PR's which are meant to either directly or indirectly improve the performance of VectorMap). Like @Ichoran said, these results are by conclusion saying that Vector is a pointless collection and we should instead be using IntMap which would be raising quite a few eyebrows.

In any case I agree with the 2.13.1 milestone, will give us time to iron out what is going on here.

I agree it seems best to get to the bottom of how it is that Vectors are slower than IntMaps before counting TreeSeqMaps as faster. Good thing we'll have plenty of time to figure it out.

Good thing we'll have plenty of time to figure it out.

Time passes quickly when a release is coming up. I don't think we should do it in a point release anyway. Switching to a different default implementation with different performance characteristics is too big a change for 2.13.x.

for PRs that are unable to progress in 2.13.x (e.g. because standard library bincompat is frozen until after Scala 3.0), we are closing them but leaving them on the 2.14.0-M1 milestone so we can find them later

for context on this, see scala/scala-dev#661