I'd like to point out how how nice the tenor of the conversation was between HJW and Markus.  Unfortunately, discussion boards often devolve into ranting from either side which helps no one.

As a rule of thumb when working with strings:
- Casting from a numeric stream to char is problematic. It is important to consider the input encoding (equally in Matlab and in Octave). Use `native2unicode` instead of casting to char.
- It it not save to expect a complete code point entity when indexing into a character array (equally in Matlab and in Octave). Octave has the function `unicode_idx` to somewhat mitigate this issue.

I don't mean UTF-16, I mean uint16, as most chars seem to be stored internally in Matlab. When using functions like strrep, multibyte characters either result in an error (if you keep the class uint8), or lead to a different result from that in Matlab (if you cast to char).

An alternative to completely overhauling Octave might be to overload the size/numel/subsref(/more?) functions for char to hide from the user that their char isn't stored as uint16. That way the interface to the user will be the same as in Matlab, which is what I'm after anyway. I personally don't care if a scalar char is one or more bytes, I just care that it is a single character. I suspect reasonable minds can disagree on that.

As far as the FileExchange is concerned: as the code for most of my submissions is also on GitHub, I don't see why Mathworks would get any say over who is using the code. They even have a category they auto-populate: https://www.mathworks.com/matlabcentral/fileexchange/?category[=1459] (although some of these are about sound). Even if I agreed to that kind of exclusivity, others can still get my code, as it is CC-by-nc-sa (which they (only) allow if you host the code on GitHub).

> I guess volunteers tend to work on the features that interest them.  If you want to bump the priority, would you like to work on this feature or perhaps pay someone to work on it?

Fair point. My problem is that I don't have enough passion for this to go and learn C(++). With my Matlab background, I try to keep all my code compatible, but I think that is where my prowess ends.

I'm afraid my financial means are restricted to the buymeacoffee-level. As I understand it, rewriting char to be 16bit exceeds that by quite a lot.

> It is possible to use UTF-8 characters in Octave.

I was not aware this would work: fprintf('%s\n',uint8([226 140 154]));  (although on my Windows machine that prints the emoji twice). I stand corrected, I should have said 'chars with values above 255'. I will look into the uint8 work-around for my use cases, thank you for the suggestion.
 

> What do you mean by "text reader"?

Out of what I described in bug #51707 grew my FileExchange submission 68780: readfile() - a general purpose text file reader.

> Which ui elements don't work correctly with UTF-8 characters?

I haven't noticed something missing, hence the distinction between files and UI elements.

It is possible to use UTF-8 characters in Octave.

What do you mean by "text reader"?

Which ui elements don't work correctly with UTF-8 characters?

Which severe limitations do you see?

See also bug #43099.
Many of these issues will be solved when MXE builds are made with Qt5 rather than Qt4 together with the patch in bug #49386.

I'll cc John Donoghue as he is the most active mxe-octave dev.

See also bug #46855 & bug #49222 that undoubtedly motivated this bug report.

I'm sure this has come up in the past several times, though I can't find the bug reports. IIRC it has been mentioned with the symbolic package as well.

There's a relevant wiki page here:
http://wiki.octave.org/International_Characters_Support
See esp. the paragraphs "The state of Octave" and further.

In Octave, one char seems to be one byte long always. This leads to the following issues when reversing or indexing into a character array with multi-byte characters:

t='abcäöü'
t(end:-1:1)
size(t)
t(4:6)

In Octave:

>> t='abc\303\244\303\266\303\274'
t = abcäöü
>> t(end:-1:1)
ans = �öä�cba
>> size(t)
ans =
   1   9
>> t(4:6)
ans = ä�

In Matlab:

>> t='abcäöü'
t =
abcäöü
>> t(end:-1:1)
ans =
üöäcba
>> size(t)
ans =
     1     6
>> t(4:6)
ans =
äöü

I also noticed that char() doesn't support values >255 and messes up Unicode characters >127:
In Octave:

>> char (269)
warning: range error for conversion to character value
ans =
>> char(228)
ans = �

In Matlab:

>> char(269)
ans =
č
>> char(228)
ans =
ä

Is this a design choice in Octave? Would it be possible that Octave's char class treated Unicode characters as such no matter how many bytes they use in any encoding (UTF-8 seems to be a good choice)?