Thanks for being patient with the recent refactoring. I know it sucks when I break your code. :wonder:
I fixed freeing the animation name (good catch!).
Extending RegionAttachment as you did works even though it doesn't expose init/deinit functions because RegionAttachment doesn't allocate for any of its fields. If it had init/deinit, they would just call the Attachment_init/deinit functions. That said, you're right that since you don't see init/deinit it indicates RegionAttachment is not designed to be extended.
The recent refactoring removed the rendering from the data objects to reduce the inheritance required to extend spine-c. Previously RegionAttachment had to be extended because it knew how to draw itself. Now something external takes RegionAttachment and knows how to draw them.
RegionAttachment needs some knowledge of the region. This allows RegionAttachment_updateOffset to handle whitespace stripped and/or rotated regions. It also allows spine-c to have AtlasAttachmentLoader so it doesn't need to be implemented for each toolkit. I agree it would be better not to reference AtlasRegion. Instead we could copy the necessary data into RegionAttachment fields. If the data comes from a different atlas, then it will work just the same. RegionAttachment would also get a void* for the region's texture, which is a renderer specific pointer. I'll make these changes tomorrow.
Is there a reason you don't use AnimationState? I only glanced briefly, but I see you have some rather complex transitions, maybe AnimationState can handle that for you?
