>Editors should maintain the visual column offset where possible, meaning they must account for double-width emoji

Im confused by this. A terminal is conceptually a grid of rows and columns. A double width char, as the name implies takes up 2 squares in this grid, so maintaining the visual offset would be the path of least resistance.

So how is the terminal being modelled, so that this statement isn't obvious and automatic.

It's quite difficult to handle double width characters and emojis reliably on all modern terminal emulators

First, the application and terminal must agree which Unicode characters are double width, as in take up two cells and move the cursor by two positions. Terminals vary at this.

Second, many emojis aren't single Unicode characters. Those are each a single emoji generated from certain sequences of combining characters with a base character. The application and terminal have to agree which sequences combine in this way, as well as how wide to display the resulting emoji. Terminals vary at both of these. Example: https://github.com/alacritty/alacritty/issues/3975

Third, IIRC some terminals treat emojis as moving the cursor by two positions because they use an approximately square space, some terminal do not and the emoji overlaps the next character.

Fourth the terminal might not be in UTF-8 mode so will treat the characters differently if it isn't.

I agree it's difficult to handle, it's difficult to handle because a terminal assumes one character == one cell. but to me the difficulty would seem to come from getting the cursor to select the entire letter rather than the individual cell.

Which is why I'm confused about the model they're using.