This feature conflicts with whitespace-at-line-end rules, because if your editor truncates ws at eol, it must account for multiline string literals in a generic way, and if it doesn’t, everyone else editing that file has to deal with ················’s scattered randomly all over the text/code/diffs. Especially when “·” renders as as “ ” instead, and pressing the End key turns into a lottery. I can see ways for this mode to remain tempting to someone, but it’s just incompatible with everything beyond that editing session.
I don't see why this is so. I like auto removal of trailing space, I don't see why you can't combine that feature and virtual space. Virtual space just means the cursor/caret moves strictly vertically as you press the up/down keys even as you visit lines that are shorter than the current offset from the left margin. If you alight at such a line and start typing text, the editor simply inserts sufficient spaces to extend the shorter line to the current offset before it inserts the text you are entering. If you are entering only spaces, that's fine too but unless you enter something else at some point all the excess space can be trimmed when you leave the line.
Auto-removal of trailing space is only possible if the trailing space is meaningless. Many programming languages have meaningful trailing spaces which cannot be removed. The most common example is inside multi-line strings.
Fair enough, I agree that virtual space is not useful or even possible if you can't or don't want auto trimmed trailing space as well. Fortunately there are many workflows and languages where auto-trimmed trailing space is a plus, and these overlap with my areas of interest.
