Both @vkrause and @markusfisch recently took part in discussions touching on the issue of handling binary data in the Result of ReadBarcode, see e.g. here. I believe there have been others in the past as well. As far as I currently understand the problem space, it looks like this:

Barcodes can contain text (as in unicode) and/or binary data. Our current interface does not give any clue what kind of data is stored inside the std::wstring Result::text() member. Then we additionally have Result::rawBytes() which is possibly also not on the right abstraction level (something about still containing error correction codes or format specific block layout issues that the client of that code might need to know about comes to my mind but my memory is foggy and I did not want to do a thorough investigation right now).

But as @tailsu rightly pointed out here, we actually have potentially the situation where those two parts of the content would need to be kept separate (text/binary) in the result to really be able to handle it properly. Heuristics like the one incorporated here by @vkrause are bound to fail, once there are actually both types of data contained inside one symbol. Maybe that is a totally esoteric/niche use case that we don't need to worry about? I'm not interested in adding a complicated 'ordered list of segments of varying data types' kind of interface that no one needs!

May I ask @gitlost how zint is handling this potential mix of data types in one symbol?

Side note: somewhat related to this discussion is the fact I'd very much like to switch from the Windows centric std::wstring to a utf8 based std::string representation of the result text (see http://utf8everywhere.org/ for a motivation :)). This would basically remove the need for everyone to deal with TextUtfEncoding helper functions and remove the glaring inconsistencies in the Result regarding string types we have today.