Show multiple last values for all eligible Overlays, not just Building overlay

[mnalis]

Introduction

Regarding caching recent answers, there are several "types" of overlays:

1. Street lighting, Surfaces - simple single answer based overlay, currently remembers only 1 recent answer
2. Buildings - also, simple single answer based overlay, currently remembers multiple (one row) recent answers
3. Places, Things - have advanced multiple recent answers UI (as it needs to show not just picture but also text description, so eats up whole screen)
4. Sidewalks, Bike paths, Street parking - have more complex orientation dependent UI (with 1 recent answer cache)
5. Addresses - does not make sense to have "recent answers" (it needs incremental answers, which are provided by its separate highly-efficient UI).

(Inspired by #5539 (comment))

Use case

"1 recent answer cache" helped in lot of cases when it was introduced! However, surprisingly often, answers alternate between last 2 (or even 3 or 4!) values for type 1 above (Surfaces & Street lighting overlays).

For example, dirt surface becomes grass (or compacted) on paths, or asphalt switches to paving_stones and then back to asphalt in cities (esp. on crossings), or lit / not lit changes depending on main street / side alleys while one walks.

In all those cases, "1 recent answer" does not help at all, and user has to do full selection (including scrolling and searching), which wastes clicks and time, and is mentally taxing and not fun.

Proposed Solution

I would like for Street lighting and Surfaces overlays to also have multiple (one row) of recent answers, just like Buildings overlay does. That would:

• fix the described use case, reducing the number of clicks and searching/scrolling through the list when user needs to select that other recently used value
• reduce number of different Overlay UIs for "recent answers" (by converting type 1 from introduction to type 2).

[westnordost]

For overlays with the street side select UI, it would make the display too busy.

For street lighting, it makes little sense, because it doesn't change in one place all the time. Either it is almost always lit (city), or not lit (forests, countryside). For surfaces, yeah, it can make sense. At least asphalt and paving stones are really common choices.

In general, there is not that much space in the quest form, as we also want to support smaller devices. One row of quick select buttons makes the UI already quite too busy for my taste.

The argument about consistent UI is convincing, though. It may pose an opportunity to reduce the code, too.

I shall consider this suggestion when I rebuild the UI for these forms in Compose.

[mnalis]

For street lighting, it makes little sense, because it doesn't change in one place all the time. Either it is almost always lit (city),

Just to note that this probably depends on the city (and esp. smaller towns or suburban areas where it seems more common), there are e.g. cases when main street is lit, but alleys / service roads / even smaller residential roads forking off / crossing it aren't. And as that long main road is often split into several segments, needs arise to tag "lit, not lit, not lit, not lit, lit, not lit..." sequences. Also in parks/cemeteries/etc. with main footway vs. smaller ones. But I guess that might be hugely country dependent too (with more prosperous countries having basically everything lit in residential areas) 🤷‍♂️

---

Anyway, if not using extra space is paramount, at least extra 1 common value, i.e. 2 total (and possibly up to 4 total!) could be fit in the same amount of space as is currently used (for both lit and surface overlays), e.g. marked with red square in this v60-alpha2-based mockup:

But yeah, surfaces are my prime interest too, so even just an improvement there would be a big win already.