The cursor position is sometimes reset elsewhere in the file after a paste. Typically, and hopefully by spec, the cursor or insertion point would be positioned at the end of the paste. When the jump happens, 70--80% of the time the cursor jumps to the very start, or to very end of the file. Hypothesizing here---some memory is not being re/initialized, and random data is used for the cursor position. When the value is out of bounds, it is interpreted as fail-safe low: go to position zero, or fail-safe high: go to EOF. Sometimes the value is just some random place within the file! Woe to s/he who was already typing post-paste, thinking s/he knew where s/he was in the file! Next, a paste will often create an inviolable amount of white space above the paste. The cursor cannot be positioned into this space, click as you might. When an insertion is made prior to the beginning of the new paste, the Inviolate White Space disappears (and the lower part of the file scrolls up).  The vertical height of the IWS seems to be about 7 lines for me, and is independent of the length of the pasted selection. Before you type to remove the IWS, scroll the page: sometimes the window acts as if an opaque empty frame overlays there and lines of text disappear behind it! (And try to scroll up, i.e. backwards, in a long file after such a paste: the window fights you every inch of way! It does not obey my mouse! It does not obey the arrow keys!) OSX 11.6, TextEdit Version 1.16 (365.2). This bug can be triggered pasting from one plain text file to another. It may be more frequent when the paste starts or/and ends at the left and right margins respectively. That is, triple-click to grab a whole paragraph as the selection, then copy.