Unicode fully defines the set of characters that should be regarded as terminating lines in Annex 14, with more in section 5.8 of the standard. These are
- U+000A Line Feed (LF)
- U+000D Carriage Return (CR) alone
- CRLF as one indivisible sequence
- U+000B Line Tabulation (VT) — supporting this is explicitly optional, and the main standard's newline function definition does not include it (so probably don't)
- U+000C Form Feed (FF)
- U+0085 Next Line (NEL), an EBCDIC round-trip compatibility character
- U+2028 Line Separator (LS), not on your list, nor
- U+2029 Paragraph Separator (PS)
As a practical matter, however, most of these will never be encountered in source text for a language developed today — they are backwards-compatibility encodings for EBCDIC and physical teleprinters.
The most inclusive approach is to take all of these, but there's unlikely to be any ill effect from taking only the standard (CR)?LF pairing, and editors generally treat the rest as control characters, not line endings.
The only other one you'll plausibly encounter is LS, which is very occasionally used for unambiguous line marking. Even that is generally ignored — VS Code actually warns you when you load the file and offers to remove (not replace) them.
If you're working on an EBCDIC machine then you can take NEL too, but line endings are a more complex question on those platforms and so something more tailored will be better.
Of special note is bare CR. Most code editors will still accept this, but don't create new files in that format, so code in a language you're creating now isn't going to use it. The most common way to end up with a lone carriage return these days is a LF-based editor that has mangled CRLF and inserted something in the middle. Treating it as a line increment only compounds the problem here, as the line number won't match how the file is displayed anywhere. Sniffing for line endings to guess is not constructive for a programming language; if you're targetting classic Mac OS or Oberon, you'll know it already.
My suggested line endings are those that match
/\r?\n|\u2028/ at most, or even just
/\r?\n/, and to make the presence of any of the other characters in the file an immediate error. If it's to be any broader than that, the only consistent choice is to match the full Unicode list, but for human-edited source code they won't actually appear.