...

1. We should decide whether or not emit on change should be considered Kafka's default behavior (i.e. we completely forgo the current emit on update design and migrate to emit on change).
2. The second option would be to add configuration to disable emit on change, but this could potentially add undesired complexity to our current API. We will need to add this config if it has been determined by a performance benchmark that emit on change severely impacts processing throughput / latency (the main latency incurred here would probably be loading prior results, if we are going to follow through with this approach).

Proposed Behavior Changes

With the current default model of emission, we are forwarding the processed results downstream regardless if  it has changed or not. In the future, this KIP aims to remove noop results from making it further down the Kafka Streams topology. There is no other major change that would be 

Implementation

Details on Core Improvement

...

To resolve this situation, the current best bet is probably to load the timestamp along with the hash code / full prior result. 

Added methods

TBD. Discussion required first.

Proposed Changes

Describe the new thing you want to do in appropriate detail. This may be fairly extensive and have large subsections of its own. Or it may be a few sentences. Use judgement based on the scope of the change.

Compatibility, Deprecation, and Migration Plan

...