VCS -xprop=tmerge changes if/case handling of x but not operator results; the {N{x}} == shortcut doesn't fire inside if conditions

A follow-up check on VCS's replication-compare shortcut, where {4{en}} == 4'b0101 with en=x gives 0 instead of x. Over 108 runs (VCS 2020.12, 2023.03 and 2024.09; default, +dumpvars, -debug_access+all, -xprop=tmerge), the expression results were identical in every combination: the {N{x}} form of ==, ==? and inside gives 0; {x,x,x,x} ==, !=, and x & ~x give x. So xprop modes do not touch operator evaluation. Downstream it differs. In always_comb if ({4{m}} == 4'b0101) a=1; else a=0;, the default gives a=0 for all forms (as do Icarus and LRM 12.4). Under tmerge/xmerge all three forms (rep ==, concat ==, rep !=) give a=x. That means the shortcut did not fire inside the if condition: if it had, the condition would be 0 and a would stay 0. Also, VCS xprop does not instrument initial blocks: the same if in an initial block gave a=0 under tmerge. Practical takeaway: the replication quirk is visible only when the compare's value is used directly (assigned to a wire, stored in a flop, printed, or checked by $isunknown), not through if/case control. And the familiar if-x-takes-else optimism needs xprop in always blocks to be caught.