I agree that there is a gap in Typst regarding customizability. I wouldn’t call it a design flaw as that would indicate that the design prevents us from filling the gap, but both design and implementation work is yet to be done to fix the situation.
I’ll link a few resources regarding related topics:
- Types and Context | Laurenz's Blog – a blog post on a possible future with custom types
- Elembic – an experimental framework adding custom types to Typst
- Interoperability & Standards between packages – another topic about interactions between packages. Not too much discussion, but I added some resources there as well and maybe someone wants to revive discussion there too.
I personally think that custom types will change the answers to the “how to configure packages and templates” question quite drastically, so I’m holding back on trying to find answers right now. It’s a bit contradictory, but I also agree with you that getting some experience with how custom types may behave would help getting them right, so Elembic is pretty valuable in this regard and maybe I should play with it (but I’m also a bit skeptical that using Elembic in a public “production” template is a good idea).
You are asking the right questions and we should definitely think about them before it’s too late; both wrt. custom types and with what problems custom types won’t solve on their own.