Thanks for insight on “locality notes”, I understood how that feature exists now (which I never used before myself and so is the user raising this bug report I feel)
just as recap, what is happening is: when a user picks a coordinate via map picker or via search text or directly as a point tap on map, there is a googlemaps GeocodeService search API request for those place text or coordinates that inturn finds a place guess, and this is inturn saved as a “locality note”. Now when the same user edits these coordinates again, such “locality note” is not touched by inat unless they manually edit that note again.
An user can edit this “Locality notes” (text that google said first) before saving as a way to correct the Google maps guess better (say if that place is not present in google maps in first place and user wants to record it better) and this is the current design case.
But I do feel there is a bug and that problem comes from two different features merged into that one text, aka an user manually creating their own locality note versus an user never creating such locality notes manually in first place - both of these are not decoupled although they should be. The latter is what happened in this bug report (and I am sure many users do the latter too)
Ideally, I think the code should decouple user-generated locality note edits (detectable by final note text different from google maps API place result) or auto-generated API place notes, and in the latter case (as in this bug report) such place-locality-note text should always reflect the latest true API results on future edits always since there is no reason to preserve the locality text - which was never a manual entry - and the system is wrongly assuming these are manual entries and should be preserved as absolute when they have just come from actual pins or text search
https://forum.inaturalist.org/t/is-this-a-location-saving-bug-in-inaturalist/78720/