First. The context that should be used to resolve ambiguity. Is the content of text a context? It surely is. But just like in malcome patch - system language is also a context.
Yes it is, and I would be happy to use it. But someone needs to code a list of ambiguous chars. Malcome's patch affects many half-width chars.
Now I can see, that someone editing Japanese in monospace might want to force half-width into the full width grid too, and even that is ok. Only not as default. Just because a systems codepage is Japanese does not mean that a latin "A" becomes double-width. That would have to be an option, that needs explicit enabling.
Further more:"system language is also a context." A context. One, but not the only one. The problem here is that if the System decides that a char has a certain width, then one must be carefully about enforcing another. (See the link you posted).
In most cases enforcing a bigger width is a lesser issue. So ok, there would be a risk, that an ambiguous char on a Japanese PC has some extra spacing. Not good, but well.
Then there is the problem what happen on a none Japanese system. Many ambiguous chars are narrow. So that should be the choice, or should it not? In a latin text you don't want a quote to introduce an extra space, don't you?
Only depending on font some, but not all, ambiguous chars may be double width, and forced to narrow they will overlap....
So this issue affect none Japanese setup too. (Actually maybe only if East Asian fonts are installed).
Anyway I am taking it further than the current issue needs: Detecting the codepage is fine, *IF* there is a list of ambiguous chars. More fixes will be needed, but it is a good start.
Second. SynEdit considers all text as full-width anyway (it doesn't have half-width!).
SynEdit name for "full-width" is "double-width".But that is naming. SynEdit has 2 widths for monospaced chars. (And more for tabs)
I presume SynEdit stops treating any unicode sequences as monospace characters and tries to render then as a single line of text. (cyrillic too?) Maybe an exception should be made for unicode characters from CJK group? In this each character would be rendered as full-width monospace characters. That should look as expected.
I'd think that having CJK characters as sort of exception should do the trick easily.
SynEdit treats everything as monospace, except that mono = duo.
If not Japanese would not behave with SynEdits grid. East asian fonts on windows use some sort of font fallback.
If not forced by SynEdit then Japanese would have aprox 1.7 the width of a latin char. SynEdit expands that to factor 2.
If that was not done SynEdit (expecting everything to the grid) could not place the caret correct.
If Japanese chars would be allowed their desired wide, SynEdit would need to support proportional font behaviour to place the caret correct. (Maybe some day, but coming from the history SynEdit has, that is not possible now)