On the instance. My understanding is that in this example, the instance itself is the key and is only stored in a dictionary owned by the related class. Maybe there are other or broader use cases, but for this particular case, storing dependents on the instance seems to (AFAICS) solve the problem without adding complexity.
Agreed. If the dictionary is owned by the related class, and classes aren't collected themselves, then there's no point in using an ephemeron table. From a GC perspective, an ephemeron table entry can be seen as a tuple <M, K, V> where V is alive if both M and K are alive. Sort of a strong edge to V from the conjunction of M and K. (A regular strong edge is a tuple <K, V> where V is alive if K is alive.) So if the ephemeron table M is known to be alive, then it collapses down to a regular strong edge, the simplest forms of which are plain properties or dictionaries mapping Ks to Vs.
I have to admit, given the obviousness of that solution, I decided that they must have some constraint we don't know preventing it. I don't know why they didn't use it here. The broader design and use-cases have been better described by sfink in these threads.
