Hello Gregor, thanks for your detailed comment!
Do you still have plans to enhance TypeScript support?
We absolutely do! It’s something we have had in our backlog for a long time and we’re finally going to get started very soon.
At the current state (v4.6) it still feels quite rudimentary and like an afterthought. Interfaces are missing a lot of properties that are present at runtime, so I have to either create my own interfaces, add as any or add @ts-ignore comments. For instance the ctx is missing type definitions for request, response and state. Also it would be great to have better native support for model schemas in e.g. custom controllers and services.
You’re right on all the different points you’ve mentionned. And all of them are topics we’re planning to tackle when working on adding TypeScript types support to Strapi.
As a small reminder/context, 4.3 included TypeScript support which included the possibility to create a Strapi project using TypeScript, but it didn’t come with integrated types or anything like that (well except for a small bonus util that served as an experiment for user type generation and that you can run with yarn strapi ts:generate-types --verbose). The main goal was to make it possible to work with TS & Strapi, even if it’s not perfect.
However, we are very well aware that it’s far from enough, both for us as contributors and also for the developers trying to build complex applications based on Strapi.
The future of Strapi x TypeScript will thus focus on that: crafting an awesome developer experience for Strapi developers. In the best scenario, this could include types for the core Strapi APIs, a low-level type system (to work with the very generic data structures we’re used to in Strapi), Auto-generated type definition for user custom code (and schemas), loose generic types to enable customization from plugins, strongly typed content API, etc…
Of course, I won’t promise everything will be available at first. Still, we’ll make our best to couple the endless customization possibilities that Strapi has to offer with the fantastic developer experience that TypeScript can provide.
Our vision here is to incrementally build a smooth developer experience thanks to complex yet powerful Strapi x TS building blocks and then expand from there.
I have thought about creating issues/PRs for missing type definitions, but this feels like very symptomatic optimizations, and also of course I don’t know what you guys are planning internally.
We’ve received a lot of those PRs (and issues) in the year following the initial release of v4.3, but as long as we didn’t have a clear vision of where we wanted to go with TS types within Strapi, we couldn’t guide the contributors nor accepting any of the proposed changes.
Also, as you mentioned, those additions would have been at best very localized and lacked customization/generic capabilities as we didn’t have the groundwork necessary to build complex Strapi types.
The whole workflow feels like it’s not optimized for TypeScript. If I work on a plugin, I have to run build or develop on order to “push” my changes to the Strapi instance around it.
Well, this is actually in the scope of the 4.3 release 
I’m curious about what you would have imagined as an alternative workflow. (Also keep in mind that plugins are still independent Strapi pieces)
I hope with Strapi v5 you would consider writing Strapi in TypeScript from the beginning. It would enhance the dev experience immensely.
We’re exploring a lot of options and ideas for V5 
Is there a place where I could give more examples?
We’re going to start crafting RFCs once we start the TypeScript work, I think it’ll be an awesome place to collect feedback and ideas. Stay tuned!
I hope I answered your questions and concerns, and if something isn’t clear, don’t hesitate to say so,
Have a nice day!