Since 4.1 [1], the cluster-version operator has pruned ClusterVersion status.history to cap it at 50 entries.  The "Update history" section around [2] should grow an explanatory paragraph like the API has had in godocs since we landed the property [3], and which we still have today [4]:

  history contains a list of the most recent versions applied to the cluster. 
 This value may be empty during cluster startup, and then will be updated when a new update is being applied. The newest update is first in the list and it is ordered by recency. Updates in the history have state Completed if the rollout completed - if an update was failing or halfway applied the state will be Partial. Only a limited amount of update history is preserved.

With the key addition being that final sentence.

As described above, the possibility of history being elided dates back to 4.1, so a web-console context paragraph could be taken back as far as folks want.  Personally, this seems fairly cosmetic, so I'd be fine if it was only fixed in 4.11 and later, or having it taken back as far as the console folks want, either way.

[1]: https://github.com/openshift/cluster-version-operator/blob/fc7d096f5fcde2758dafd1ce968601cd774479f4/pkg/cvo/status.go#L130-L131
[2]: https://github.com/openshift/console/blob/26b3c07a8db4660f21e2fabfbfb7d23f73150247/frontend/public/components/cluster-settings/cluster-settings.tsx#L1219-L1222
[3]: https://github.com/openshift/api/commit/cae4137f1a7f94f91916f2affc4a2e3f7c02ce31#diff-1b89ebfc7018fedcaa25a406ba7d376d0aa0f025a416bd286238899b6ab7ba91R86
[4]: https://github.com/openshift/api/blame/b25f69a603a76ccc809f986c9f5811f0825febbb/config/v1/types_cluster_version.go#L98-L104