The docs instantiate classes automatically to infer default values of properties. Abstract classes cannot be instantiated. To infer default values in abstract classes, the docs will try to instantiate a subclass. This PR triggered a re-order, which made CanvasItem's 'designated subclass' be Control instead of Node2D. This caused physics_interpolation_mode to be changed, since Node2D has a different default from Control and CanvasItem.

I fixed the problem by supplying a default directly in CanvasItem explicitly. This required adding an explicit path for 'non-instantiatable objects that supply their own defaults', which was previously not supported.

I wonder if we could allow instantiating abstract classes only for doctool, to retrieve the default values properly. The current behavior of inferring it from a subclass is pretty iffy as we see here.

Otherwise yes, we'd have to sprinkle some ADD_PROPERTY_DEFAULT as needed, like we already do for some platform-specific APIs.

I support reordering registrations to be in the correct inheritance order, but I wonder: is there any actual problem caused by the existing out-of-order registrations? What are we solving exactly besides making things "correct"?

I wonder if we could allow instantiating abstract classes only for doctool, to retrieve the default values properly. The current behavior of inferring it from a subclass is pretty iffy as we see here.

Unless the class is also C++-abstract, it should be possible.

I support reordering registrations to be in the correct inheritance order, but I wonder: is there any actual problem caused by the existing out-of-order registrations? What are we solving exactly besides making things "correct"?

Yes, two problems are addressed with these changes:

• We currently have some classes with inconsistent state (e.g. using GDCLASS even though they're never explicitly registered). They often end up being registered automatically through subclasses. This can lead to unexpected behavior when querying ClassDB about these classes, or when asking them about their class name (which might not be the name of a registered class). By enforcing expected registration behavior, we can catch these problems early, which is what the eventual follow-up implements: Warn when classes are registered out of order #106873
• For performance purposes, we should start creating certain caches for Object types. The best time to create a cache is when the class is finalized. Unfortunately, some classes are registered before their superclasses, so they can't be easily finalized. I ran into this issue when creating property caches, so I had to work around the improper registration order by updating subclass caches when the super type finalizes. This will not work for every type of cache. See PR Optimize property access for Object subtypes #106646

Thanks!