Lee Carré (2021-11-01 13:57:41+00:00): “Does a session last 2 hours or what?”

By session, I meant collecting answers and uploading them. E.g. daily. The duration is up to you. Could be more than daily (multiple taxi rides, for example, with a meeting between; each taxi ride being a distinct session if one wishes).

The 2 hours refers to the timeout which OSM (backend) applies for auto-closing changesets when there's been no further additions to them. Changesets can (optionally) be immediately closed upon submission / commit, or left open (for adding more to).

In SC's auto-upload=always it keeps the (per-quest) set(s) open. Whereas in the other modes it immediately closes them.
If the timeout (2 hours) were longer (and personally I wish it was, but can imagine there being good reasons for it not being too long), then it would be less of a problem. However, what I encountered was, since I had nothing to add to that set (more answers for the same quest-type) for 2+ hours (I was answering other quests), it was auto-closed (by the OSM backend), so when I did then encounter another quest of the same type (as earlier, for the now-closed set) during that day's surveying session (I often do multi-hour ones; 12 hours being my longest so far), SC had to open (yet) another set; messy (for other mappers). Keeping manual control (auto-upload=never;manual) avoids this; they're all uploaded at the end of the day; only one set per quest-type per day. Much neater.

For context; I personally also don't encounter the problem of wide-spanning bounding boxes, because I only survey my local area (which is small to begin with). Were I to travel, then I'd have to take extra precautions (as you've now discovered 🙂).

Further info: http://wiki.osm.org/wiki/Changeset

“I've been looking for a “force upload” button and I would never have thought of turning off auto-upload to get it”

That's an insightful (usability & UI design) point. Gives me more thoughts re SC's development.

Now that I'm thinking about it, I don't inherently see why the button should be hidden when auto-upload=always. Originally the thinking may have been ‘it's pointless since there'll never be anything waiting in the queue to be uploaded’. However, the behaviour in that case could be modified to have SC close all existing sets; such as for when finished in one city and intending to survey the city one is about to travel to. The tool-tip could describe it as something like ‘I (am moving|have moved) to a different (far away) area’ (I'm reminded of old GPS receivers which had something similar, so that they would know to re-initialise (re-fetch the ephemeris catalogue) since their view of the sky had significantly changed since last used (else they're looking for satellites which are below the horizon).

Changing the icon would be most sensible, too. Though, I'm not sure to what; something to reflect the differing functionality.

“Maybe I'll open a GitHub issue for this or if you do then I'll join it, I'd like to contribute a code change if this can be improved, either with a UI change to make this button easier to find, or clarifying the consequences of the different upload options or adjusting the logic for when to upload what changes a bit.”

Oh, please do: http://www.github.com/streetcomplete/StreetComplete/issues
That's what I was intending to do, until it became clear that you're tech-savvy.
It would be much better coming directly from the user affected, rather than second-hand.
Cite this changeset there, for reference. Your comments are insightful to inform design. Especially since SC is intended for newbies and to not require knowing or understanding the underlying clockwork (which has evidently been broken / violated, in this case).
I'll gladly subscribe & chime in on the interaction-design front.

On the basis that you'll be opening the issue, my earlier thought for avoiding this case was to have SC (somehow) figure out, especially when in auto-upload=always, that the user has moved to a distant area and thus should close all previous changesets before further quest-answers are added to the queue.

While a pull-request would be welcomed by Tobias, the important thing is opening an issue for there to be a record of the problem and the ideas for a remedy. Code can come later.