Notepad (at least originally) was implemented as a simple wrapper around the Windows EDIT control. EDIT is not really designed to handle large amounts of text -- it stores text in a single block of memory allocated via
LocalAlloc (which, at least for 16-bit versions of Windows, means that it can't handle more than 64K of text in a single control, and in real-mode windows requires a contiguous block of memory to store all of it). Even in 32-bit Windows, where the memory management no longer restricts it to 64K backwards compatibility does, because the messages that are sent to it or received from it in order to allow the application to control it were only designed for the 16-bit system, and were never modified for 32-bit applications (Microsoft wanted Win32 to be source code compatible to Win16, so the existing messages had to retain the same layout).
The line breaking issues you noticed are probably due to the fact that while it can support (nearly) 64K of text, the Windows EDIT control can't handle more than 32767 characters on a single line. Copying and pasting a larger line can exceed this limit, but the line breaking algorithm seems to rely on signed integers. At a guess Notepad is reading lines out of the editor and storing them to the file one by one, and therefore gets a phantom line added where there is none in the buffer because the requested line is longer than the limit so is split into two by the edit control to pass the data back.
More advanced editors like Write and its successor WordPad don't store the entire content in a single block; they typically used a linked list of lines, so were able to handle larger files even under 16-bit windows, and don't have backwards compatibility restrictions that prevented them from changing implementations when moving to 32-bit.
 - citation needed - I know there's an article about this on Raymond Chen's blog but I can't find it right now.