To me, the main trouble with globals is merely an expression of a bigger core issue.   The bugaboo is (IMHO) really not so much that the data is in-effect scattered hither and yon, but that the logic is similarly scattered.   The latter is, IMHO, what you really want to avoid.

A simple “getter/setter object” is a little better than nothing, because it does offer a centralized place at which to validate what an object contains ... but even that objective can be muddled if, as usual, “it depends.”   These are pure-design choices with no clear bright line rule.   I think you’d like to go a few steps further than that, if practicable, just to get more bang for your buck ...

Here is what I think is a good road to take:   let your global data structures live in a singleton object, with getters and setters, “instantiate on-the-fly” capabilities, and so on ... whatever you decide you need ... and then try to minimize the number of other units that actually have to refer to the globals directly.   My analogy is:   “only the valet really knows where your car is parked, and only the cook really knows where the food is stored before it is delivered to your table.   And in both cases, only they need to care.”   The code that wants something, asks for it.   The code that fulfills that request knows about the globals singleton, and the globals singleton knows about that code.   Thus the number of packages that share code and/or data dependencies is thereby appropriately minimized.