Omer van Kloeten: your variant would require `.view` to be refined to return a `MapView`, which somehow still doesn't exist (or it would require adding `mapValues` and `filterKeys` on `IterableView[A]`, taking an implicit proof that `A =:= (K, V)` — assuming that's handled well by type inference — but that would look odd to me).

I considered suggesting such a variant of 2, but I sense current views are often considered unsatisfactory — so I'm not sure I'd propose extending them.

Finally, for such a proposal somebody should volunteer to write MapView by 2.12 — I don't want to stall this proposal.

I like #2 best of all the "let's do something" options, but we don't have to deprecate anything in order to provide an eager alternative. So I'm not entirely sure when the deprecation should hit. I'd rather put something in place for 2.12 that provides an alternative, and not necessarily make it contingent upon whether we deprecate or not.

I would be in favour of adding mapValuesNow, which already exists on s.c.i.AnyRefMap and s.c.i.LongMap. I like the name because it comes up next to mapValues in code completion. I guess we should then also add filterKeysNow. At the same time, deprecate mapValues and filterKeys.

Regarding the implementation: eager mapValues for s.c.i.HashMap can be implemented very efficiently, same for s.c.i.SortedMap. Eager filterKeys for HashMap is also possible to implement quickly.

I strongly believe deprecation is essential to proposal #2. IMO the main issue that needs resolution is warning people about filterKeys being lazy. If they already know they need a strict version they're not going to be bitten by this bug (I still call it a bug, since filter and filterKeys should behave the same way, likewise for map/mapValues).

I agree with Rex Kerr that "adding strict alternative" is technically orthogonal to the deprecation. So IMHO* somebody could already start implementing that, following Rüdiger's plans. (Even if we wouldn't do #2, we'll need the same implementations).

But Iulian Dragos is right if the overall goal of the bug is not "offer both behaviors at all" but "fix latent bugs where clients use the lazy variant but shouldn't". Under that goal, deprecation is essential to the overall goal. I think that's a good goal, since Scala tries to reduce pitfalls. The only downside is that some users will have to change their code just to confirm they mean to use the lazy version.