still not sure about this being in common

Still don't see the need for this function if we do g_CivData = loadCivData( in 7 places of gui/ without this being in gui/common/ and while only saving only 12 characters (while reserving a function name that some GUI page inheriting this common/` code might want to use)

common/ must mean that these files can only be included from the structree and entityDetails page, but basically never for a third GUI page in the public or custom mod.

Otherwise that third page is likely to specify a custom closePage mechanism. Would be cleaner to not have it in common then.

This block has braces while the others above don't

(There is a custom JS doc format for optional values, but I didn't find the benefit of using it yet)

Could use a brief comment what it contains and where it is used. It is the first line seen and as such (it's the first question that comes to the mind of readers of this file)

The public mod doesn't have any _pair. Should we incentivize modders to break the startsWith("pair") pattern?
Also startsWith("pair") -> startsWith("pair_").
Also no need to leave the impression that indexOf can return something lower than -1.

If we use === instead of == then we make sure to notice the difference between falsy and false values. So if someone passes undefined, null, 0, the code explicitly doesn't return false and attempts to iterate over reqsB.

If these cases are expected to not occur, then why does it use === instead of ==? (Same for those indexOf === -1) Just personal preference?
Maybe, but besides in this commit, we have only one other indexOf === line in gui/ (grep -R indexOf | grep '===').

In fact we only have 26 unneeded === comparisons in gui/ that can be found with:
grep -R '===' | grep -v '====' | grep '===' | grep -v structree | grep -v reference | grep -v '=== undefined'
and are a tiny minority in comparison to all the other comparisons.

might want to state that it's the raw data from the json files (most data could be considered raw)

For n=2 it's questionable whether it's worth it to write it like that (unless the array becomes a a global that could be extended for modders, if that makes any sense)

nicely readable

If that magic number needs a comment to be explained, might want to replace it with something where the syntax correlates with the semantics, i.e. ".json".length (eye candy).

(Other than that, there might be a function stripping the fileending to make it even more readable. Apparently not so... at least not in globalscripts/utility.js)

While the CodingConventions recommend those spaces for objects, it doesn't recommend them for arrays and the majority of GUI and simulation code doesn't have it

(Since the majority of structtree code doesn't add the spaces between the string concatenation operator, I didn't say anything. Other than that would be nice to keep spaces in the other code)

Pointless file. If future code uses it, it can be introduced then. Otherwise empty files seem like smoke & mirrors.
modders who have no clue of what they're doing might not have a benefit of an empty file either, as they have sufficient other GUI page examples that show them inclusion of style.xml files.

Maybe we could use the defaulting of that argument in other GUI pages too to remove duplicate 'truthy' checks.

(The GUI error that the first dropdown item is not available if there are no civs can also be prevented without closing the GUI page, a throw new Error("meh") seems cleaner)