Hi all, Thanks for the updates. Sorry for the late response, somehow the latest response was not delivered to my inbox and I had to fetch it form the mailing list archives. A few thoughts on the recent points, and a couple of follow-ups.
AS: The builder pattern is a good direction — it avoids forcing the user to reason about a mode/state machine, and it lets the existing single-partition flow stay untouched. The Compatibility section should state explicitly that existing constructors plus `createInputTopic/createOutputTopic/pipeInput/getStateStore` remain source- and binary-compatible for callers that never touch `withMultiPartitionMode()`, so we have a clear contract for existing tests. LB4: How are records with a `null` key routed in multi-partition mode? The real producer's `DefaultPartitioner` uses sticky partitioning for null keys, which would make tests non-deterministic. The KIP should specify the behavior — for example, round-robin in declared partition order, or requiring an explicit partition on `TestRecord` when the key is null. LB5: When a single `pipeInput` causes records to fan out across multiple downstream tasks, what is the processing order? A documented deterministic order (e.g. ascending `(subtopologyId, partition)`) would be valuable to state in the KIP. Thanks, Lucas
