Note that in addition to allowing different types of spaces, multiple consecutive spaces also should be permitted (showing a warning or requiring confirmation would be fine). An example where both of these problems are hit is track 3 of https://musicbrainz.org/release/948a66d5-6993-446a-9deb-cc732c5326f4 which is correctly written as

-　　　　　　　-

(i.e. a dash, 7 ideographic spaces, then another dash).

I entered this release back before the normalization changes, which is why it's still showing up correctly for the time being - but it's in kind of a fragile state due to the fact that some unrelated tracklist edit might apply normalization.

For the record, here is a list of space characters that was recommended for sacrifice on the altar of normalization; text copied from the wiki page Internationalization (imported from MoinMoin in 2005):
 

There are also ranges of Unicode characters that should be avoided as they do not provide increased range of expression but merely create interoperability issues for those without complete Unicode fonts. In particular, the following should be explicitly prohibited by style guidelines (and perhaps enforced by the database):

1. Non-breaking space U+00A0
2. Fullwidth latin and halfwidth kana/hangul U+FF00-FFEF
3. Narrow non-breaking space U+202F
4. Ideographic space U+3000
5. Medium Mathematical space U+205F
6. Typographic spaces U+2000-200B

The first [is] not specifically Unicode issue as [it] occur[s] in Latin-1, but [this] plus the [second] are among the ones where database enforcement is most desirable as they can lead to artist names that are visually identical in appearance but which are, in fact, different.

I don’t know exactly why whitespace variants have been disabled to start with, but I guess that was the easiest way to fix some bugs related to these characters. Since most of the current code is assuming these are not allowed, technical issues can be expected if these characters get entered again. Below are the few difficulties that have been reported in various discussions:

1. Whitespace variants are difficult to type in.
   Allowing variants is not the same as making these mandatory. If you don’t need it, don’t use it. Editors who need it generally know how to enter it easily. This is the same logic as letting others using alphabet you cannot even read.
2. Whitespace changes are difficult to detect.
   This can be fixed by showing edits preview for all entity types (MBS-8815) and improving diff display to render whitespace variants with substitutes.
3. Whitespace variants make search difficult in the database.
   Not with a proper search implementation and proper search queries. If there are still bugs with that, these should be fixed first.
4. Whitespace variants make search difficult in tagged files.
   Not with a tagger like Picard that has an option to standardize characters (source).

To sum up, I think we should first document that whitespace variants cannot be currently entered, then create tickets to overcome the above mentioned difficulties, and finally recommend using whitespace variants again once these tickets have been fixed.

There are many related bugs that have been reported or fixed recently, so it would be nice to take a decision now for all of further code changes.