Older similar: T103077: First heading is missing when page title is "0"

Just a thought: Could the breaking of templates by misplaced NBSPs be avoided by changing MediaWiki's parameter handling to treat NBSPs like other whitespace characters in assignments?

These seem relevant whenever there are misplaced NBSPs:
T96666: Make non-breaking spaces (nbsp) visible in VisualEditor
T181677: Implement syntax highlight for U+00A0 (no-break space, nbsp)

I suggest changing the title of this bug to "Consecutive spaces changed to NBSPs, which can break templates", or something like that.

@JoeWalsh, a question when you have found the cause of this bug:

In T201340#4486102, @MaxSem wrote:

You get what the interface tells you

Question: Before I tried to change my local preference (yesterday): Which notification settings were really in effect on the local wiki; the settings that appeared to be set locally, or those that appeared after I clicked "Save"?

Safari too for me (latest version on macOS); the Undo menu item is non-functional when the syntax highlighter (CodeMirror) is on, just like with the other browsers.

@ChristianKl, it appears you hadn't changed the setting "Days to show in watchlist" on the Watchlist tab in your Preferences. Doing this should resolve the problem but see the bug T199566, in particular the workaround at T199566#4458615.

Note: this concerns the "unimproved" watchlist.

I just noticed in mw:Manual:$wgReadOnly that this message will be preceded by the message in en:MediaWiki:Readonlywarning. Can you confirm this?

In T197134#4426697, @Marostegui wrote:

It will show: Scheduled maintenance on enwiki from 06:00-06:30 UTC..

In T197134#4426697, @Marostegui wrote:

if that is better.

Will $wgReadOnly show a message while read-only?

Another example (from User:Larske at svwiki):

jcrespo, I don't know, but see this comment by @Samwalton9:

I notice the "Access denied for user s51559" in the SUL Info error message and @jcrespo's "I have blocked the user" at T194343#4200496.

Question:
Would this bug have affected edits made with the 2017 wikitext editor in the same way as the visual editor? (That seems likely, since the 2017 wikitext editor is a mode within Extension:VisualEditor.)

Well, selecting a namespace has an automatic "Exclude unselected" effect when "Exclude selected" is not selected.

When any namespaces are selected, but "Exclude selected" is not selected, only the selected namespaces are shown, so other namespaces are effectually excluded. This is how it worked and still works with my filters (which I have kept) which were affected by the bug, and how it works with any filter.

Thank you. Then I think the upcoming Tech News is worded correctly about this.

With a thought to the Tech News notice:

@Johan, something for Problems in the next Tech News?

In T183910#3869874, @Pipetricker wrote:

in my Swedish account, I haven't made any change to my saved filters in more than a month (other than selecting active filters). I'll get back to you after the SWAT.

@Mooeypoo, as expected all my English saved filters with exclusions will need to be re-saved, while all of my Swedish old saved filters now work as they should again.

Yes, in my Swedish account, I haven't made any change to my saved filters in more than a month (other than selecting active filters). I'll get back to you after the SWAT.

Thanks @Mooeypoo.
After the SWAT, I will retry my older saved filters which have exclusions. As I said in the bug description, my default Swedish filter still works correctly on page load (but not when subsequently selected).

In T183910#3868312, @Mooeypoo wrote:

Fixed a typo that caused this. It should work now, but I can't retroactively fix the incorrectly saved queries -- after the patch is merged and deployed, please re-save the saved filters that had 'excluded' in them again.

At WP:VPT#Why am I seeing a "Welcome" message?, Whatamidoing (WMF) mentioned: "One of the devs also suggested making it possible to dismiss things like this by clicking anywhere outside the box".

In T135773#2312590, @matmarex wrote:

The translation commit above was meant to be picked up by daily LocalisationUpdate run, but that did not happen for some reason.

Perhaps T48750#2176499 has a better description of the problem.

Notice that "User:Foo_/_bar" is a subpage not of "User:Foo", but of "User:Foo_".

I found an older feature request for basically the same thing, T11578: Feature request: Direct access to the history page containing the listing corresponding to a past revision.