Yes, you will effectively need a topic per aggregation (if you have more than one partition). How you do this setup, is up to you and there is different tradeoffs as you mentioned already. If you will be able to get ordering is questionable for any solution I can think of?

If you are comfortable with switching from .NET to Java (using Kafka Streams), it might be the option with least manual toil. -- When Kafka Streams repartitions the input data using different aggregation-keys, it would also use multiple (shuffle/repartition) topics, and would introduce unorder. But you don't need to touch your upstream application which writes into the input topic, and Kafka Streams does a lot of heavy lifting for you.

You could also stick with .NET, and mimic what Kafka Streams does, but it of course much more work. And the un-order when writing into the aggregation topics is the same problem.

But frankly, I am not sure if your business logic really requires strict ordering, so the above two options might actually just work for you?

If ordering is really crucial, it might be possible to improve it, by actually having one input topic per aggregation. But it seems to be difficult to guarantee that the upstream application is writing into all input topics in the same order? And if possible to achieve this, it of course requires changes to your upstream application.