(@Tacsipacsi: Please review project tags and subscribers when creating subtasks - thanks!)

Enwiki has the opposite preference, because of https://en.wikipedia.org/wiki/Wikipedia:Manual_of_Style#Non-breaking_spaces (which technically applies only to the mainspace, but editors are used to it).

Also, if they're not converted, then the next time an editor uses https://en.wikipedia.org/wiki/User:Cacycle/wikEd then WikEd will create a dirty diff by replacing the character with the HTML code.

In T286223#7210782, @Whatamidoing-WMF wrote:

Enwiki has the opposite preference

But other wikis (probably most of them) don’t have official guidelines, so it’s the users’ own discretion whether they use HTML entities or Unicode characters. I prefer the latter; I don’t want to force it to anyone, but I don’t want to be forced to use the former either.

Also, if they're not converted, then the next time an editor uses https://en.wikipedia.org/wiki/User:Cacycle/wikEd then WikEd will create a dirty diff by replacing the character with the HTML code.

This is a very controversial feature of wikEd, removing it or at least disabling it in talk namespaces has been requested numerous times. It should be solved on wikEd’s side, not ours.

My own experience on pl.wp is the same, people dislike non-breaking spaces in the page text because other tools mess them up. Some years ago folks insisted that I change my signature to use the entity instead: https://pl.wikipedia.org/w/index.php?title=Wikipedysta:Matma_Rex/podpis&diff=next&oldid=28692050&diffmode=source

No one ever complained at me on huwiki for this, even though I always prefix my Hungarian signature with U+2013 U+00A0 (en dash, non-breaking space). I think source mode is for senior contributors, who can be expected to know the rules of their communities. I don’t like “smart” software, which knows better what I want than myself, please offer an option to use Unicode characters.

For now, we're going to leave the &nbsp behavior as it is [i].

Reasons: we are assuming there is more value in lowering the likelihood of a non-breaking space causing a dirty diff than there is in avoiding the extraneous text that is inserted into the page.

We can revisit this approach, if/when the above proves inaccurate.

i. When someone who has the source mode toolbar enabled inserts a non-breaking space,   will appear within the tool's text area.

In T286223#7260671, @ppelberg wrote:

there is more value in lowering the likelihood of a non-breaking space causing a dirty diff

Does it cause dirty diffs in DiscussionTools edits? If not, those other tools should avoid the dirty diffs, not DT. To be honest, I’m seriously considering abandoning DiscussionTools if I can’t use the Unicode characters I want (unless I can hack this bug around on my own).

In T286223#7261692, @Tacsipacsi wrote:

In T286223#7260671, @ppelberg wrote:

there is more value in lowering the likelihood of a non-breaking space causing a dirty diff

Does it cause dirty diffs in DiscussionTools edits? If not, those other tools should avoid the dirty diffs, not DT.

It does not, and you're right that it is a problem with the other tools, but in the past that did not stop people from blaming the visual editor for it (the context here is T183647), and we worry that now it also would not stop people from blaming the reply tool for it.

To be honest, I’m seriously considering abandoning DiscussionTools if I can’t use the Unicode characters I want (unless I can hack this bug around on my own).

Other options that might work for you:

• Only disable the editing toolbar in reply tool source mode (there's a setting in Preferences → Editing → Discussion pages), the nbsp stuff is part of the new editor with the toolbar
• Put the endash+nbsp into your signature in preferences rather than typing it manually, it will be inserted unchanged when it's part of the signature

In T286223#7264330, @matmarex wrote:

It does not, and you're right that it is a problem with the other tools, but in the past that did not stop people from blaming the visual editor for it (the context here is T183647), and we worry that now it also would not stop people from blaming the reply tool for it.

But that report was about random places, and has been fixed, hasn’t it? Random  s are more annoying and the tool is more likely to be blamed than  s appearing at places where they actually make sense. But if you really want to hide it, even a hidden preference, a JS hook, whatever, is better than nothing.

Other options that might work for you:

• Only disable the editing toolbar in reply tool source mode (there's a setting in Preferences → Editing → Discussion pages), the nbsp stuff is part of the new editor with the toolbar

I know about it and have already disabled it (I don’t really need the toolbar anyways), but it isn’t supposed to stay forever (T276607: Converge on a single DiscussionTools source mode). Or have your plans changed? (I mean the preference may stay, but it doesn’t matter once the VisualEditor editor appears even without the toolbar.)

• Put the endash+nbsp into your signature in preferences rather than typing it manually, it will be inserted unchanged when it's part of the signature

Unfortunately this doesn’t work for me. Sometimes I want to put an unprefixed signature in a template parameter, sometimes I want to use another prefix (for example when writing in English), not to mention the pain of configuring the signature in each and every wiki individually.