the first one may not (at least in principle) be the primary set of coordinates for the page

In practice, too; I'm not sure about ordering, but an article might have secondary coordinates but no primary coordinates.

IMO secondary coordinates don't really belong in a summary; there can be any number of them, they can describe anything with the loosest relation to the subject, and the client has a name to go on at best; so I can't imagine a non-confusing way of exposing them on the UI. IMO we should only return primary coordinates.

Globe and dimension (useful for choosing default zoom level) can just be added to the output. Or we can just remove non-Earth globes so old clients do the right thing, and re-add them in some way that's only recognized by new clients.

The other fields (type, region/country, name) are probably not really useful.

Is this only for the summary endpoint or also for the mobile-sections endpoints? I guess whatever we do for summary witht he geo property should also be done for mobile-sections.

I agree that we should only use primary coordinates in the summary. It's probably the same for mobile-sections.

Does anyone we know use the geo property in the summary endpoint? I don't see any usage of the summary geo property in the Android app.
@phuedx or @Jdlrobson Does mobile web use it? I have a hard time finding the MFE code for page previews.

In T179947#3742908, @bearND wrote:

Is this only for the summary endpoint or also for the mobile-sections endpoints? I guess whatever we do for summary witht he geo property should also be done for mobile-sections.

I agree that we should only use primary coordinates in the summary. It's probably the same for mobile-sections.

The summary endpoint is now basically piggybacking on the logic for constructing a page lead object, so whatever choice we make for the mobile-sections/formatted page lead will apply to both. The logic in the description is followed in constructing the page lead, and so is inherited by the summary endpoint.

Conceptually, providing secondary coordinates in the section endpoints makes sense (more than having them in the summary, anyway). In practice, I doubt they would be useful. Maybe in the glorious future when those location objects include a Wikidata ID and can thus provide rich metadata about themselves; right now the client can't really tell what it is getting coordinates about.

Change 410087 had a related patch set uploaded (by Mholloway; owner: Mholloway):
[mediawiki/services/mobileapps@master] Ensure lead section 'geo' property is valid

https://gerrit.wikimedia.org/r/410087

Change 410087 merged by jenkins-bot:
[mediawiki/services/mobileapps@master] Ensure lead section 'geo' property is valid

https://gerrit.wikimedia.org/r/410087

Change 416459 had a related patch set uploaded (by Mholloway; owner: Mholloway):
[mediawiki/services/mobileapps@master] Hygiene: Stop checking coordinates for legacy MW API booleans

https://gerrit.wikimedia.org/r/416459

Change 416459 merged by jenkins-bot:
[mediawiki/services/mobileapps@master] Hygiene: Stop checking coordinates for legacy MW API booleans

https://gerrit.wikimedia.org/r/416459