At least they use it in their docker images. Reproducible: Always
Does it collide?
Define "collide". If we are talking about other acct-user package or user.eclass definition in portage tree, then no. If we are considering real world use cases involving www-apps/grafana-bin installed with emerge, the answer is "it doesn't matter, we cannot do anything about it as UIDs are already there". End users can experience problems of different severity if they have Grafana data obtained as a backup from other server or via running Grafana inside a docker container on Gentoo-based host
So it would be solved when migrating www-apps/grafana-bin to acct-user when getting a new uid?
I double checked the ebuild of grafana-bin it has no hard coded uids, so 472 might be on your system but that can change. In first place grafana-bin should be migrated to acct-user with a requested fix uid in https://api.gentoo.org/uid-gid.txt
I'm not talking about Gentoo-specific UID for Grafana here. 472 is the UID Grafana upstream seems to prefer and hardcode in some places (like in their docker image).
This is not a problem. When GLEP 81 was new we tried to match upstream IDs for unknown reason. This was changed later, see https://archives.gentoo.org/gentoo-dev/message/9601d9904bf97d88349d41ab7d3a4eb7 where the discussion started.
