Here are some solutions that I've considered:

1. immutable objects
   a. make the objects truly immutable/const
      * not trivial, if possible
   b. make the objects effectively immutable
      * (see GH-24828) use a really high refcount to make races irrelevant
2. per-interpreter objects
   a. replace them with macros that do a per-interpreter lookup
   b. replace them with simple placeholders and do a per-interpreter lookup internally
   c. replace them with PyObject placeholders and do a per-interpreter lookup internally

As far as I'm aware, only (1b) and (2c) are realistic and won't break the stable ABI (i.e. preserve layout).

(FWIW, I think that even with (1b) we would still have per-interpreter objects.)

-- Regarding (1a) --

See see GH-24828 for an example implementation.  This includes storing some state for the objects in PyInterpreterState and doing a lookup internally.

pros:
* relatively straightforward to implement
* overlaps with other interests (see bpo-40255)
* makes the objects shareable between interpreters (making them more efficient)

cons:
* we have to ensure the objects stay immutable (a tractable problem if the solution is constrained to only the limited API objects)

-- Regarding (2c) --

This involves adding an API to get the per-interpreter object for a given identity value (flag, global, etc.) and then mapping the limited API objects to the corresponding per-interpreter ones.

pros:
* avoids a one-off solution
* extensions can stop using the variables directly (in favor of the new lookup API)

cons:
* effectively couples the C-API to the design (as long as the objects are in the limited API)
* many touches all over the C-API
* any future changes/additions in the C-API must deal with the objects