Sorry - I should have been more clear. I was hoping to discuss specifically the asset system and the new important (rather than the module system and the new template broadly). My project (a) currently uses a custom TSShapeLoader plugin and AppMesh subclass, and (b) doesn't have a clear path to integrate with the current asset system, so I want to make sure that the current shape loader architecture will remain suitably flexible and see if we can't figure out how to make the asset system a little bit more flexible as well.
Ahh, I see what you mean now.
Yes, I plan to ensure that all current functionality that the shape loader is replicated in asset management(and then some!) in context of being able to modify a shape on/post import, associate materials and animations to a given shape asset and all that jazz. I don't believe it'd be hard at all for you to replicate any customizations you did in the shape and animation asset loading code.
That said, in the near-term, shapes will still operate primarily on the TSShapeLoader/Constructor stuff and go through the resource system internally. Near-term, assets are more about convenient management and tracking/usage of said assets, than a radical redefinition of how they're processed internally. That'd be the long-term goal so things are cleaner and more consistent, but the near-term shouldn't see any major waves on the backend side of things.
I can give you a specific example case in my RnD brach stuff if you're curious, but as said, the ShapeAsset, for example, is currently more about tracking/usage management than a new paradigm in how the resources are actually loaded in context of the engine.
If there's any particular things you did/plan to do you're thinking specifically, lemme know and we can talk more in-depth on the particulars, but I'm 100% confident we'll be able to make it work with minimal fuss going forward.