Hmm, it depends on how merging works b/w primary & replica? E.g. we could merge only on primary and copy merged segments out. Yes, this is added bandwidth, but then merging is also CPU / IO intensive, so saving that work for the replicas may net/net be worthwhile. And copying out a merged segment to a replica can be a lowish priority thing, e.g. it need not gate NRT reopen time (just like how IW's merged segment warmer doesn't either).
But yeah if the replicas do their own merging, somehow with a merge policy that's guaranteed to precisely match what the primary does (despite e.g. ConcurrentMergeScheduler causing merges to complete in different orders), then we would need to somehow set the IDs of the merged segments on the replicas to match the corresponding merged segments on the primaries. Or, perhaps ... we compute the ID of a merged segment by hashing the IDs of the N segments that were merged ... hmm risky because if there were different deleted docs then the IDs should differ, so maybe we hash on that too ... tricky.