I believe he's trying to print the 0..9 range by providing the proper start and end point for those characters but instead gets 9..0 (I don't know the script but I'm basing it off by the 0 at the end). So for instance 0x07c0 stands for 0 in Nko script, and this is his starting point, but the entire sequence ends up being reversed. I'm not sure how comparing it to JS helps here other than I guess pointing out that it's also behaving unexpectedly.

Wait, I just realized the results in my repl (0..9) are reversed from what I pasted into HN (9..0). And if you shrink the width of the browser to force my HN snippets to wrap, it changes the order. And it selects in the reverse order on click and drag.

I spoke way too soon. Unicode is weird. My apologies to our friend UncleEntity.

It looks like it depends on how your terminal (or the browser, or anything that renders it) handles Unicode (which I guess just means that Unicode is hard to get right): https://i.imgur.com/8FPNYMP.png

It's how the directionality (right to left or left to right) is decided that is complicated for mixed texts (and always nothing but a heuristic).

I must admit that I was surprised that the following snippet kept the LTR order in my terminal:

>> [(chr(ord('0')+i), chr(0x07c0+i)) for i in range(10)] [('0', '߀'), ('1', '߁'), ('2', '߂'), ('3', '߃'), ('4', '߄'), ('5', '߅'), ('6', '߆'), ('7', '߇'), ('8', '߈'), ('9', '߉')] >>> [(chr(0x07c0+i), chr(ord('0')+i)) for i in range(10)] [('߀', '0'), ('߁', '1'), ('߂', '2'), ('߃', '3'), ('߄', '4'), ('߅', '5'), ('߆', '6'), ('߇', '7'), ('߈', '8'), ('߉', '9')]