Hi Leonard and Anton, Thanks for the suggestions. I agree that non-tiered PK reads should be a follow-up and need not block FIP-50. FIP-48 can remain lake-scoped.
In Java, the KV and lake scanners handle their source-specific input collection separately, while sharing the final snapshot/changelog reconciliation and delete handling through SortMergeReader in fluss-client. We can follow the same boundary in Rust without adopting the sort-merge algorithm itself. The existing hash-overlay logic, including tail folding, tombstone handling, base-image reconciliation, and survivor emission, can be made source-neutral and moved from fluss-lake into the core crate. The lake path can use it with a lake snapshot, while a future non-tiered path can use the same component with a KV snapshot from ScanKv. This avoids duplicating merge and delete semantics and provides the foundation for the engine-neutral current-view contract Leonard suggested. Thanks Anton for the clarification and for the detailed update! Best, Jim
