I'm on the VS Code team and maintain xterm.js which is what Hyper's frontend is based on. There are actually multiple developments happening in this area.
First, there's a contribution from the author of DomTerm which adds grapheme cluster support to xterm.js, which will correctly merge and size things like emoji that are called out in the post. This is currently based on Unicode 15. See https://github.com/xtermjs/xterm.js/pull/4519
Second, while Windows Terminal does seem to work with emoji sometimes, it doesn't all the time. I'm not 100% sure, but I think it may only work on Windows ptys, not in WSL for example. Last time I spoke with the team they said they're working on a rewrite which could lead to proper emoji support.
I'm the author of DomTerm and the above-mentioned xterm.js PR. Both use the full UnicodeGrapheme Cluster Boundaries algorithm (https://unicode.org/reports/tr29/#Grapheme_Cluster_Boundarie...). However, I haven't seen any specifications for how wide the resulting clusters should be in a mono-space context. So unless we enhance terminals to handle variable-width fonts (which I've been thinking about), we need to took at other terminals and make judgement calls. Generally, the width of a cluster is the width of the widest codepoint. Also, I decided that a "normal" character followed by emoji-presentation makes it 2 columns wide.
In your linked-to article, you suggest 2-em dash and 3-em dash should be 3 and 4 columns respectively. That might be reasonable, but it is explicitly contrary to the EastAsianWidths specification. You also suggest that Pictographics fullowed by text-presentation should have width 1. That seems reasonable, though I don't implement that.
To my knowledge, there is no specification for monospace width. Applying the East Asian Width attribute as a proxy does not work reliably. So in my opinion, it is all a matter of agreeing on what's reasonable while keeping it simple. I.e. if allocating text-presentation Pictographics to a width of 1 is reasonable, that's what renderers should do. It's what users would expect.
First, there's a contribution from the author of DomTerm which adds grapheme cluster support to xterm.js, which will correctly merge and size things like emoji that are called out in the post. This is currently based on Unicode 15. See https://github.com/xtermjs/xterm.js/pull/4519
Second, while Windows Terminal does seem to work with emoji sometimes, it doesn't all the time. I'm not 100% sure, but I think it may only work on Windows ptys, not in WSL for example. Last time I spoke with the team they said they're working on a rewrite which could lead to proper emoji support.