This is a known class of GitHub behavior rather than a go-ethereum problem.

The /releases/latest and /releases/tags/{tag} endpoints do a direct lookup of a single release record, so they'll always find v1.17.4 as long as the release object exists. The /releases list endpoint and the web Releases page, however, are served from a separate listing/index — which also has no guaranteed sort order (it's effectively ordered by created_at, i.e. the tag's commit date, not the publish date).

When a release object exists but isn't correctly indexed into that listing — which can happen when a release is created against a tag that already existed, or via automation — you get exactly this symptom: reac…