If you're designing a text editor that's intended to run within a browser you need to fully break user expectations about the functionality of the tab key - there are two completely logical and intuitive roles it can serve in such an environment that are in conflict.

The same issue arises (with much higher frequency) with Enter and even in the modern world I'm sure we all have a pretty complex ruleset we've committed of when ctrl+crlf triggers a newline, or a message send and what the corresponding behaviors of a bare crlf and shift+crlf are.

In HN's editor shift+crlf and a bare crlf cause a newline creation and ctrl+crlf does nothing - but often times ctrl+crlf will trigger a form/message/whatever submission, shift+crlf often causes a raw newline insertion (even when in a form context) and then a bare crlf might do one - might do the other or might even do neither! Those are the common bindings but I have seen exceptions and inversions of bindings with shift+crlf causing form submission while requiring ctrl+crlf for raw newline insertion.

All this stuff is just super annoying and causes a lot of user friction (and for a long time MSFT's style guide was considered a seminal reference for best practices as ironic as they may seem to folks these days).