For now it seems that the active_locales for root page (that are then offered as the languages available for the home page translation) are taken from metadata/404.json instead of say e.g. metadata/mozorg/home.json — either by the fact it's the first file in the folder, or that's the actual page that serves the root?

Compare ./manage.py active_locales mozorg/home (expected locales)
to ./manage.py active_locales 404 (that are in reality used for the home root links)

Basically none of the root language selection gets filtered to PROD_LANGUAGES or DEV_LANGUAGES, only to locale map from product-details, otherwise anything that's in the metadata json as active_locale gets exposed all the way through.

Actually not only there are disabled languages being offered. There are also a handful missing: https://www.textcompare.org/?id=66cf6c8bba091793598346ea

(full diff in the link, but basically some European and Asian languages like az, bg, et, gu, hy, lt, ta, ur missing.)

1. So for this root page to correctly reflect the available locales for homepage (i.e. those that would be alternate hreflangs for /en-US/ and are correctly offered there), this root has to list active_locales not for its request, but for mozorg/home.ftl instead.
2. Also to avoid providing broken links in case there are active_locales that are however not allowed in PROD_LANGUAGES, a filter to only allow PROD_LANGUAGES needs to be added.

This is getting a bit complicated now with three home ftls:

1. mozorg/home-m24.ftl
2. mozorg/home-new.ftl
3. mozorg/home.ftl

with varying activation metadata.

Normally a "good enough" check might be for the activation of the oldest home.ftl file for home-old (?xv=legacy) that is the "lowest common denominator" fallback if nothing better exists, however this is not 100% correct:

A corner case might be e.g. a locale that never had home-old or home-new translated, but got active recently and completed home-m24 localization — such language should also be listed in the global root as active.