Yep — leading spacer is handled the same as the trailing one. In the egui path we skip both flags and don't put a real cell into the text run; copy goes through alacritty's bounds_to_string, which also drops those spacer cells. So you shouldn't get an extra space at the wrap. If you do hit a case where selection still picks one up, send a repro — that'd be on our selection path, not the merge.
csmlab notes
On the wide-character part: when a double-width character arrives with only one column left, alacritty_terminal pads that cell with a LEADING_WIDE_CHAR_SPACER flag and wraps the character to the next line. Does MistTerm's run merging treat that leading spacer the same as the trailing WIDE_CHAR_SPACER cells, or does it skip it? Copying text across that wrap is where I'd expect a stray space to show up.