Understanding the Normalize Text Command

OR, as is frequently the case in Office programs, a command is built for an activity in a context that you are not in.

(One could regard the example given, of working only upon Asian language charaacter typing, as a context, and since you are not doing so, you are not in that context and so the command has no effect upon what you are seeing or working with. A little bit of "tenuous" applies to regarding it that way, but surprisingly little.)

In this case, what I've found suggests that the command is for use in building custom UI's and, POSSIBLY, in the particular area of Tables. So if not building a custom UI using an XML schema, then it simply has nothing to do when running it. (And actually, some posted commentary says it can seem to run, but end up grayed out and inaccessible afterward with no obvious effects having occurred. Comparable to a website presenting you a two step task, say to download Google Drive files, in which it presents the download option, spends 20 minutes zipping files, then tells you "Oh, you can't really do that" and you're done. Instead of examining the proposed operation, deciding you can't do it, ending things there, and never making you wait 20 minutes for the zipping that was never going to be needed: so Word shows a huge list of commands without examining which CAN be run in your situation (context), letting you choose an inapproptiate one and after finding it is that, only NOW graying it out or removing it from the list... in other words, AGGRAVATING!)

Naturally, that doesn't in any way further explain what it might bring to the table if you are in a context it is meant for. But the context aspect matters a lot for many commands and functions. They can be richer, or sparser, depending upon their use context. For common things, that can be readily apparent due to grayed out choices and so on, but many times, especially for more specialized uses, MS does not go to the effort to "prettify" the function: or in other words, dumb it down for the masses (like me), rather expecting anyone who is there and about to use it to bring with him the knowledge to handle the small stuff.

A guess, given the custom UI aspect? The guess is that it would attempt to establish a pattern for the existing creation (as in identifying headers and titles vs. end result text (kind of like building an outline structure)) and then applying the formatting shceme for other elements in the structure according to the understanding of the structure it was given as an example. So one layer of titling might get Bold, 16 point font formatting while a sublayer might get not-Bold, 14 point formatting, and a bottom layer might get not-Bold, 12 point formatting. More or less like marking some text as the pattern text, the program building an ad hoc Style, then applying it to anything else in the available layout that it can identify as matching the marked pattern-generating material. So your custom UI would be a consistently formatted structure, not a badly non-professional "ransom note" of formatting.

That guess is "way, way, way... out on a limb" to say the very least. Context, though, is often hugely important and seems to be so here as well.