What do you mean not designed for Korean? It's just unicode. If there's some situation where RST isn't parsing inline markup, you can write the role explicitly like this:

  this is **bold** text
  this is :strong:`bold` text

▲ rune-space 4 days ago | parent | next [-]

But you can’t say:

   thisis:strong:`bold`text

Whereas the equivalent is perfectly fine in markdown.

Falsehoods programmers believe about written language: whitespace is used to separate atomic sequences of runes.

▲

thaumasiotes 4 days ago | parent [-]

> Falsehoods programmers believe about written language: whitespace is used to separate atomic sequences of runes.

Really? That isn't just untrue of written language in general. It's untrue of every individual written language in specific. You can't even clearly define what an "atomic sequence of glyphs" is.

	▲	matja 4 days ago \| parent \| next [-]
		> You can't even clearly define what an "atomic sequence of glyphs" is. Kinda. Grapheme cluster breaks are defined in Unicode, but they have all the baggage and edge-cases you'd expect from human languages evolving over time, so they can be encoded in as a few as a thousand rules : https://github.com/unicode-org/icu/tree/main/icu4c/source/da...
	▲	rune-space 3 days ago \| parent \| prev [-]
		Which makes one wonder why REST puts so much weight on them being divided by WS!

▲ lifthrasiir 4 days ago | parent | prev [-]

reST inline syntaxes are pretty much word-based, which doesn't work very well with agglutinative languages. For example if you want to apply a markup to "이 페이지" in "이 페이지는 ..." (lit. This page in This page is ...), you need to do `*이 페이지*\ 는 ...` AFAIK. That would happen every single time affixes are used, and affixes are extremely frequent in such languages.

	▲	do_not_redeem 4 days ago \| parent [-]
		Oh I see, you're talking about this: thisis\ bold\ text thisis\ :strong:`bold`\ text It's possible, but you're right, definitely more awkward than markdown.