Given that the class still needs to opt in to this new core behavior with IS_POSSIBLE_GDCLASS, I feel the incentive to get this in core isn't that clear cut. The local solution in #88689 seems much simpler, and both cases still require recognizing and properly handling the uncommon pattern used by such classes.

If we could make it automagical so this pattern works out of the box, the core approach would make a lot of sense IMO (provided it doesn't add too much complexity or impact negatively the other, more common patterns).

But that's just my non-expert opinion. I'd wait to get input from @reduz and @RandomShaper who might like this approach. That might take a while to assess, so in the short temr I suggest we merge #88689 (and this PR can then be rebased to undo the change for #88689 that wouldn't be needed if this approach is merged).

Without having assessed personally the classes involved in the issue, this is my take:

• First, I agree that this PR (although I acknowledge its advanced C++ merit!) is too much to add to something as core as Object for such a marginal use case.
• Second, I'm sure an alternative design is possible where multiple inheritance is not needed. Again, I haven't checked the issue in detail, but this sounds like some of those cases where composition can be used once simple inheritance doesn't scale.

If we could make it automagical so this pattern works out of the box, the core approach would make a lot of sense IMO (provided it doesn't add too much complexity or impact negatively the other, more common patterns).

It's possible to write the template to automagically detect the situation, but, unfortunately, it requires the full definition of Object be available, which we can't really do for all the places that memory.h is being used.

• First, I agree that this PR (although I acknowledge its advanced C++ merit!) is too much to add to something as core as Object for such a marginal use case.

Understood! I guess I'll just close this one then :-)